Adding a new Model Context Protocol server to an agent usually takes a few minutes: point the client at the server, approve the tool list, and the agent can suddenly read files, hit APIs, or run commands it couldn't touch a moment ago. That speed is the appeal of MCP, and it's also the risk. The integration step and the permissions decision look identical from the developer's side, but only one of them gets reviewed with any rigor.

Most teams treat a new MCP server the way they'd treat a new npm dependency: check that it does what it claims, skim the README, and move on. But a tool server isn't a library that runs in your process under your control — it's a separate service the agent can invoke autonomously, often with credentials scoped far more broadly than the task actually requires. A server built to "manage calendar events" might expose delete and share operations nobody on the team ever intended the agent to reach. A server wrapping a database might return raw query access when only three specific lookups were ever needed.

What to check before you connect a server

Before wiring a new MCP server into an agent that can act on its own, walk through four questions:

  1. What's the actual tool list, not the marketing description? Call the server directly and enumerate every tool it exposes, including ones that seem unrelated to why you added it. A "send Slack message" server that also exposes "delete channel" is a different risk profile than the name suggests.
  2. What credentials does the server hold, and what do those credentials permit outside the tools it exposes? If the server authenticates with a token scoped to full account access, the agent's effective permissions are the token's permissions, not the subset the tool descriptions imply. Scope the credential down to the minimum the intended tools need, even if the server would technically accept a broader one.
  3. Does the server validate its own inputs, or does it trust whatever the model sends? Some servers pass arguments straight through to an underlying API or shell command with no validation. If the model can be induced — by a prompt injection in a document it reads, for instance — to call a tool with unexpected arguments, a server with no input validation turns that into a real action.
  4. What does a bad call look like in your logs? If the server doesn't log which tool was invoked, with what arguments, and on whose behalf, you have no way to reconstruct what happened after an incident. Treat tool-call logging as a prerequisite for connecting the server, not a nice-to-have you'll add later.

Scope per agent, not per integration

The deeper mistake is treating MCP server access as a single on/off switch for the whole system. A support-ticket triage agent and a code-review agent might both want a GitHub MCP server, but the triage agent has no legitimate reason to open pull requests, and the review agent has no reason to close issues. Wiring both agents to the same fully-permissioned server instance means every agent inherits the union of everyone's needs.

Where the server supports it, run separate instances or separate credentials per agent role and grant only the tools that role's job actually requires. Where it doesn't, that's a real limitation worth flagging back to whoever maintains the server, not a gap worth quietly working around.

None of this is exotic — it's the same least-privilege discipline teams already apply to service accounts and API keys. The difference is that an agent decides for itself, call to call, which of its available tools to use, which means the review has to happen before you grant access, not after you see how the agent behaved.

AI SecurityAgentic AIMCPModel Context Protocol