Fixing “Tool Amnesia” in Model Context Protocol Ecosystems | by Prachi Panditrao | Jul, 2026 | Towards AISitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Towards AI

We build Enterprise AI. We teach what we learn. Join 100K+ AI practitioners on Towards AI Academy. Free: 6-day Agentic AI Engineering Email Guide: https://email-course.towardsai.net/

Fixing “Tool Amnesia” in Model Context Protocol Ecosystems

A Java Gateway Router pattern for reducing prompt bloat, preventing parameter hallucination, and preserving tool context.

Prachi Panditrao

4 min read·<br>5 hours ago

Listen

Share

Press enter or click to view image in full size

Picture this: You’ve just discovered the Model Context Protocol (MCP), and you’re hooked. You build a couple of custom Java tools, link them up via your ⁠mcp.json⁠ file, and watch Claude or Cursor execute them flawlessly. It feels like magic.

So, you do what any good engineer does – you scale it. You add a few more custom tools for internal APIs, and then you install a handful of popular, off-the-shelf MCP extensions for GitHub, Jira, and Slack to supercharge your workspace.<br>Suddenly, your AI environment is packed with dozens of tool descriptions and complex JSON schema definitions. You run a test query, and… crash.<br>The LLM completely hallucinates a parameter name, mixes up two different arguments, or completely forgets that your tool even exists. Welcome to Tool Amnesia .<br>Here is why this happens across both off-the-shelf IDE extensions and custom backends, and how you can fix it using smart architectural guardrails.<br>The Root Cause: Attention Dilution & Token Bloat<br>LLMs don’t natively understand what an MCP server is; they just read text. When an MCP client (like Cursor, VS Code, or Claude Desktop) boots up, it reads every single active tool name, argument schema, and description text, and injects it straight into the LLM’s system prompt.<br>If you scale up your setup, you quickly run into two major flavors of this problem:<br>The Custom Server Struggle: Context Drift<br>When developing custom tools, it’s easy to let parameter schemas drift. If Tool A expects⁠ repositoryId⁠ and Tool B expects ⁠repo_name⁠, a confused LLM dealing with a crowded system prompt will often split the difference and pass ⁠repoId⁠ – instantly throwing an ⁠IllegalArgumentException⁠ on your Java backend.<br>The IDE Extension Explosion: Marketplace Bloat<br>This isn’t just a custom code issue; it’s an ecosystem-wide challenge. Popular public MCP servers are incredibly dense because they are built to handle every possible use case out of the box. For example, the official GitHub MCP server exposes over 90 separate tools .<br>Get Prachi Panditrao’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

Subscribe

Remember me for faster sign in

Plug just three or four standard extensions into your global IDE configuration, and you are forcing the AI to process 150+ tools before you even type a single line of code. The token overhead is massive, stretching the LLM’s attention mechanism to its breaking point. In fact, coding platforms like Cursor enforce strict ceilings (often around 40 – 50 active tools) because pushing past it causes the underlying LLM’s tool-selection accuracy to plummet.

Solution A: The Java Gateway Router (For Custom Backends)<br>Instead of exposing 30 granular micro-tools directly to the LLM, compress your interface. Expose just one highly robust wrapper tool to the LLM, and let your Java server handle the routing deterministically.<br>// Instead of dozens of individual @McpTool annotations, use a Gateway Tool<br>@McpTool(description = "Executes core repository operations like fetch, commit, or rollback")<br>public String executeRepoAction(<br>@McpParam(description = "The specific action intent (e.g., 'fetch', 'commit')") String intent,<br>@McpParam(description = "Key-value pairs of required parameters") Map arguments<br>) {<br>// Let Java do what it does best: ultra-fast, type-safe routing<br>return switch (intent.toLowerCase()) {<br>case "fetch" -> repositoryService.handleFetch(arguments);<br>case "commit" -> repositoryService.handleCommit(arguments);<br>default -> "Error: Unsupported action intent.";<br>};<br>}Defensive Parameter Normalization : Inside your Java service, you can easily catch common LLM parameter hallucinations using clean fallback maps:<br>public String handleFetch(Map arguments) {<br>// Intercept variations caused by context drift<br>String repoId = (String) arguments.getOrDefault("repositoryId",<br>arguments.getOrDefault("repository_id",<br>arguments.getOrDefault("repo_id", null)));

if (repoId == null || repoId.isBlank()) {<br>return "Error: Missing required parameter 'repositoryId'. Please explicitly provide it.";<br>return repositoryService.fetchData(repoId);<br>}If the LLM misses the mark slightly, your code bridges the gap. If it misses it entirely, the structured error string guides the LLM to self-correct and retry automatically without crashing the application...