Wiring MCP Servers Into an LLM Code Security Agent

An LLM security agent is only as good as the tools it can reach. The reasoning is the visible part, but the part that decides whether the agent is reliable — or a liability — is the plumbing underneath: how it authenticates to a code-search server, how its tool schemas are shaped, what happens when a tool errors, and whether re-running an action is safe. This post is about that plumbing. Specifically, it is about wiring tools and Model Context Protocol servers into a Claude security agent without creating new attack surface or flaky behavior. Model Context Protocol is an open standard that lets a model invoke external tools and data sources through a uniform, typed interface, which is exactly what a security agent needs to reach code, history, and a sandbox without bespoke glue per integration.

Pick the right tools, then make them narrow

A code security agent typically needs four MCP-backed capabilities: code search and definition lookup, git history and blame, dependency and advisory lookup, and a sandboxed execution runner for proofs. The temptation is to expose broad, powerful tools — "run any shell command," "query any database." Resist it. Each tool should do one narrow thing with a tightly typed schema, because the schema is both your safety boundary and the model's instruction manual. A tool called read_definition(symbol: string, repo: string) is safer and easier for the model to use correctly than a general run(command: string) that happens to be able to read definitions.

Narrow tools also fail more legibly. When find_callers returns nothing, the meaning is unambiguous; when a generic shell tool returns nothing, the model has to guess whether the command was wrong, the symbol does not exist, or the repo was misnamed. Constrain the surface and you constrain the ways things can go wrong.

Authentication: scope down, never hand the agent your keys

The agent must never hold broad credentials. Each MCP server authenticates with its own least-privilege identity: the code-search server gets read-only access to the specific repositories under review; the git server gets read-only history; the sandbox runner gets no production credentials at all. The agent itself holds none of these — it calls the server, and the server holds the scoped token. This separation means a prompt-injection payload hidden in source code cannot trick the model into exfiltrating secrets, because the model never had them in the first place.

flowchart TD
  A["Claude security agent"] --> B{"Choose tool"}
  B -->|search| C["Code MCP: read-only repo token"]
  B -->|history| D["Git MCP: read-only blame"]
  B -->|prove| E["Sandbox MCP: no prod creds, no egress"]
  C --> F["Validate args & scope"]
  D --> F
  E --> F
  F -->|ok| G["Typed result"]
  F -->|bad| H["Structured error: code + hint"]

The diagram makes the trust boundary explicit: every path passes through argument validation and scope checks before any real action, and the sandbox path is deliberately starved of credentials and network egress. Treat the source code under review as untrusted input — because in a security tool, it literally is — and let the servers, not the model, enforce what is allowed.

Schemas are the contract; make them strict

A loose schema is a bug generator. Define each tool's arguments with explicit types, enums where values are bounded, and required fields, and reject anything that does not conform before the handler runs. If repo must be one of a known set, make it an enum so an invented repo name fails validation instead of reaching the filesystem. Strict input validation does double duty: it stops malformed model calls cheaply, and it documents the tool well enough that the model rarely calls it wrong.

Shape the outputs too. Return structured results — a list of matches with file, line, and snippet — rather than a blob of text the model must re-parse. Structured outputs reduce the chance the model misreads a result and let you cap response size deterministically, which keeps a single search from blowing the context budget.

Error handling the model can actually act on

When a tool fails, the worst thing it can do is throw an opaque stack trace into the conversation. Return structured errors with a machine-readable code and a short, actionable hint: { "error": "SYMBOL_NOT_FOUND", "hint": "No definition for that symbol; try search_code with a substring" }. This turns a dead end into a recoverable step — the model reads the hint and tries a different tool. Distinguish retryable failures (a timeout) from terminal ones (a symbol that does not exist) so the model retries the former and changes strategy on the latter instead of looping.

Set hard timeouts and budgets on every tool, especially the sandbox runner. A proof script that hangs must be killed and reported as a timeout, not left to consume the run. And cap the number of times the agent may call any single tool per task, so a confused loop terminates with a partial result rather than burning your budget.

Idempotency: make re-running safe

Agents retry. Networks blip, the model re-issues a call, CI re-runs the job — so every tool must be safe to invoke more than once with the same arguments. Read tools are naturally idempotent. The one that needs care is the sandbox runner: give each proof attempt a deterministic key derived from the candidate and the script, and have the server return the cached result for a repeated key instead of spinning up a second container. The same discipline applies to any tool that writes — a finding-recording tool should upsert by a stable fingerprint, not append, so a retry does not create a duplicate finding.

Idempotency also keeps your audit trail honest. When each action is keyed and cached, the transcript shows one logical operation even if it was physically attempted twice, which makes replaying and debugging an agent run far less confusing.

Frequently asked questions

Why narrow tools instead of a general shell tool?

Narrow, typed tools are both a safety boundary and a clearer instruction for the model. A tool that only reads a definition cannot be coerced into exfiltrating data the way a general shell command could, and its failures are unambiguous. Broad tools expand attack surface and force the model to guess what went wrong.

How do I stop prompt injection from source code?

Keep credentials out of the model entirely. Each MCP server authenticates with its own least-privilege, scoped identity and enforces what is allowed; the agent never holds a broad token. Source under review is treated as untrusted input, so even if a payload manipulates the model's reasoning, there is nothing sensitive for it to reach.

What needs to be idempotent and why?

Anything that executes or writes. Agents and CI retry, so the sandbox runner should cache results by a deterministic key per proof attempt, and a finding recorder should upsert by a stable fingerprint rather than append. Without idempotency, retries spawn duplicate containers and duplicate findings and corrupt the audit trail.

Bringing agentic AI to your phone lines

CallSphere wires tools into voice and chat agents with the same rigor — scoped auth, strict schemas, graceful errors, and idempotent actions — so an agent can check a calendar or update a CRM mid-call without ever overstepping, around the clock. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.