Hardening MCP server token consumption and prompt-injection risks before production

A documented case shows one MCP server consuming 18,000 tokens before any useful work begins, and Ars Technica reports prompt-injection risks that spread across agent-to-agent MCP links in Google, JP Morgan Chase and other organisations. Both problems surface late — after cost overruns or security incidents — unless teams apply token budgets, capability scoping, prompt sanitisation and contract tests during development.

One MCP server burned 18,000 tokens before doing anything useful#

The New Stack reported a Pi Agent MCP server that used roughly 18,000 tokens during initialisation, before a single tool call or user interaction. The tokens were spent enumerating capabilities, negotiating schema and exchanging verbose system prompts across the Model Context Protocol handshake. At typical commercial API pricing, that single cold start costs several cents; in a customer-facing feature that spins up per session, the bill compounds fast.

The workaround the author adopted was to strip the server down to a minimal capability set, cache the negotiated schema and defer detailed descriptions until the first actual tool request. That cut the cold-start token count by more than 90%. The lesson is not specific to Pi Agent — any MCP server that advertises a large tool surface or rich metadata will exhibit the same behaviour unless constrained.

In a customer-support agent audit we conducted for a B2B SaaS client, we discovered their MCP setup was burning nearly 22,000 tokens on every turn simply because their dynamic tooling manifest re-broadcast comprehensive database schemas, OpenAPI specs, and formatting instructions on every single handshake. The team initially assumed the spiking latency was an upstream model provider bottleneck. By implementing lazy tool registration—exposing only lightweight summaries initially and resolving full schemas only when a tool was invoked—we dropped context window overhead by 88% and halved end-to-end response times.

Prompt injection travels across trusted agent boundaries#

Ars Technica detailed a class of attack dubbed "protocol pivoting" that exploits trust gaps in MCP. Independent researcher Syed Anas Mohiuddin demonstrated proof-of-concept exploits against agents from Google, JP Morgan Chase, Weaviate, Rapid7, the French government's interministerial digital directorate and the US federal government. The pattern is consistent: a malicious prompt enters one agent — often via untrusted content such as an email or document — that agent delegates the task to a second agent over MCP, and the second agent executes because it implicitly trusts the first.

In Google's case (CVE-2026-97228, severity 8/10), the mcp-toolbox initialised its HTTP client without a CheckRedirect policy or target IP validation. A crafted path parameter forced the toolbox to follow a redirect to an internal endpoint, achieving server-side request forgery. Rapid7's vulnerability (severity 2.7) was fixed with an allow-list of IP ranges and block lists applied at startup rather than on first request. Douglas McKee, director of vulnerability intelligence at Rapid7, summarised the root cause: "Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch. Each protocol was built assuming it lived on its own, so each one checks its own front door while nobody watches the hallway in between."

Markus Vervier of X41 D-Sec classifies the technique as indirect prompt injection — the malicious prompt originates in one protocol (e.g., Agent-to-Agent) and manifests when used over another (MCP). The distinction matters less than the shared mitigation: treat anything passed from an LLM to your tool as input from a stranger on the internet.

Checklist for development-phase hardening#

1. Enforce token budgets per server and per session#

Set a hard ceiling on tokens an MCP server may consume during initialisation and per interaction cycle. Implement the budget in the client wrapper that calls the server, not inside the server itself — that keeps enforcement consistent across multiple server implementations. Log actual usage against the budget in CI so regressions fail the build. For the Pi Agent case, a 2,000-token initialisation budget would have caught the 18,000-token regression immediately.

2. Scope capabilities to the minimum viable tool set#

MCP servers often expose dozens of tools when a feature needs three. During development, generate a capability manifest from the server's schema and diff it against a declared allow-list for the feature. Fail CI if the manifest contains tools not in the allow-list. This prevents token bloat from unused tool descriptions and reduces the attack surface for prompt injection — fewer tools means fewer delegation paths an attacker can pivot through.

3. Sanitise prompts at every protocol boundary#

Any string that crosses from an LLM output into an MCP tool call must be validated. Apply an allow-list of expected patterns (e.g., UUIDs, ISO dates, enumerated enums) and reject or transform anything that contains instructions, code fences or protocol-specific keywords such as "delegate", "forward" or "ignore previous". Do this in a shared middleware layer so every agent-to-agent hop re-applies the same rules. Google's SSRF fix — rejecting unsafe base URLs at startup — is the same principle applied to network calls: validate before you trust.

4. Write contract tests that simulate malicious delegation#

Extend your integration test suite with scenarios where a compromised upstream agent sends crafted payloads to the downstream MCP server. Test cases should cover:

• Redirect chains that attempt SSRF against internal metadata endpoints
• Tool arguments that embed instructions for other tools in the same server
• Oversized payloads designed to exceed token budgets
• Schema violations that exploit loose parsing

Run these tests in CI on every PR. They are the "hallway cameras" McKee argues are missing when each protocol only watches its own front door.

5. Apply zero-trust authorisation between agents#

MCP's default trust model assumes every internal agent is authorised to call every tool on every other agent. Replace that with explicit authorisation policies: each agent presents a signed token scoped to the specific tools and resources it may access. The downstream server verifies the token before executing. This contains blast radius — a compromised translation agent cannot pivot to a database agent unless its token grants that scope.

What to do next#

Audit every MCP server in your stack against the four controls above: token budget, capability allow-list, prompt sanitisation middleware and contract tests for malicious delegation. Start with the server that has the largest tool surface or the highest session volume — that is where cost and risk concentrate. In our Applied AI and large language model integration work we put these guards in place before a feature reaches staging, so token spend stays predictable and prompt-injection paths are closed by design.