Trust comes before connect

Almost every tool in the agent stack assumes the connection has already happened. Permission scopes, audit logs, rate limits, sandboxes — they all govern what a server does once your agent is talking to it. The decision that actually carries the risk is the one nobody instruments: should you have connected to this server at all?

Model Context Protocol (MCP) made it trivial to point an agent at a new server. That was the whole win — a server is now a URL and a handshake away. But the same move that made connecting cheap also made the connection the moment of maximum exposure, and we still treat it as a formality. You read a name, maybe a one-line description, and you wire it in. From that point on, the tool descriptions the server hands you are inputs your model will act on.

Where the risk actually moved

In the old integration model, connecting to something was expensive and deliberate. You wrote a client, you read the API docs, you handled the edge cases. The act of integration was itself a long review. By the time a service was in your stack, several people had looked at it.

MCP collapsed that. Connecting is now a config line, and the review that used to be smeared across days of integration work has nowhere to live. So it mostly doesn't happen. The risk didn't disappear when integration got cheap — it moved to a step we no longer perform.

Tool descriptions are input, not documentation

Here is the part that catches people. When your agent connects to an MCP server, the server returns a list of tools and a natural-language description of each one. Your model reads those descriptions to decide what to call and when. That means the descriptions are not documentation for a human — they are prompt-adjacent input from a party you have not vetted, flowing straight into the model's decision loop.

A server doesn't have to be malicious for this to bite. A description that overstates what a tool does, or quietly implies it is the right tool for a job it is wrong for, will steer an agent just as effectively as an honest one. You find out by watching the agent do something you didn't expect, and then tracing it back to a sentence you never read.

What a real pre-connect step looks like

Evaluating a server before you trust it doesn't require a security team. It requires three things to be fast enough that you'll actually do them: see the tools a server exposes, read what it claims each one does, and run one against a throwaway context to confirm the claim matches the behavior. None of that should take longer than reading the README would have.

• Enumerate the tools and resources the server exposes — the real list, not the one in the marketing copy.
• Read each tool description as if it were going into your prompt, because it is.
• Invoke one or two against a disposable context and compare what happened to what was advertised.
• Only then wire it into anything that holds state or credentials.

The reason this isn't standard practice yet is friction, not disagreement. Everyone nods along that you should look before you connect. Almost nobody has a fast way to look. So the look gets skipped, and the first real inspection of a server happens in production, performed by an agent, on your behalf, with your credentials.

Why we built around this

MCPOrbit's design target was to make the pre-connect look cost less than skipping it. Point it at a server, see every tool and description it exposes, and run one without committing the server to anything. The goal is narrow on purpose: collapse the time between 'I'm considering this server' and 'I've seen what it actually does' to under a couple of minutes, so the inspection stops being the step you rationalize away.

Connect is the easy half. The protocol already nailed it. Trust is the half still waiting for tooling, and it's the half that decides whether the easy connection was a good idea. Look first.