{
  "id": 13237809,
  "title": "Your MCP Server Is Wasting Your Agent's Context Window",
  "url": "https://urgent.news/2026/10/09/your-mcp-server-is-wasting-your-agents-context-window",
  "topic": "ai",
  "section": "AI",
  "published": "2026-10-09T22:31:39.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/jeff_pdc/your-mcp-server-is-wasting-your-agents-context-window-54ea"
  },
  "original_language": "en",
  "account": "You have created a powerful MCP server, listing 42 tools with comprehensive schemas, granting the agent full access to internal systems such as your API, database, and deploy pipeline. However, three weeks later, you notice the agent is struggling to retain earlier instructions, hallucinating tool names, and hitting token limits during tasks. Assuming the model is inadequate, you switch to another model, but the issue persists. The problem lies with your MCP server using the agent's context window as a dumping ground.\n\nMost MCP servers expose every tool at session start, consuming a significant portion of the 200k-token context window before the agent has even read the first line of your codebase. On a well-built internal API with 30 endpoints, this can consume 8-15% of the budget. The agent doesn't require all 30 tools; it needs only 2, specifically the ones for file operations and test execution. The remaining 28 tools are unnecessary clutter that hinders the agent's performance.\n\nTo address this issue, you should split your MCP server by capability rather than resource. Instead of a monolithic server with all tools, create narrow servers for specific tasks, such as file operations, testing APIs, and deployment. This approach allows the agent to load only the necessary tool for the current task, resulting in a fraction of the resource consumption and an improvement in the agent's success rate for narrow tasks.\n\nAdditionally, return concise error messages instead of lengthy payloads when a tool fails. A 400-line stack trace is counterproductive, as the agent will read it, yet it may still make the same incorrect assumption. Instead, provide a 2-line error code, a pointer to logs, and a hint about the problematic parameter. This allows the agent to request further details if needed.\n\nAnother optimization is to let the tool descriptions guide the model on when not to invoke a particular tool. For example, use specific disambiguators for production deployments, and advise against using them for staging. The model can utilize these cues to select the appropriate tool, reducing incorrect calls and retries.\n\nLastly, version your tools and deprecate them clearly. If you have both v1 and v2 of the same endpoint, mark v1 as deprecated in the description. While agents may still call the deprecated tool, reducing its usage over time, you can eventually remove it once telemetry confirms zero calls. Keeping both versions alive unnecessarily inflates the tool count.\n\nTo validate your server's efficiency, generate it from an OpenAPI spec rather than hand-creating it. A spec-driven generator produces a tight, consistent tool list, with one tool per operation and predictable parameter names. This approach eliminates duplicate endpoints, resulting in a smaller server that aligns with the paths the agent actually requires. By versioning the OpenAPI spec and removing deprecated paths, you maintain a minimal server that optimizes the agent's context window for the actual problem at hand.",
  "summary": "You wired up a great MCP server. It lists 42 tools, each with a detailed schema, and the agent now has full access to your internal API, your database, your deploy pipeline. Three weeks later you notice the agent is forgetting earlier instructions, hallucinating tool names, and hitting token limits halfway through a task. You assume your model isn't smart enough. You switch models. The problem…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}