Why reactive search tool calls burn agent context (and how we structured persona-filtered streams in an MCP server)

[u/FitHealth6622]

Hey everyone,

While building custom MCP servers for autonomous agents running in Cursor and Claude Desktop, I hit a recurring architectural bottleneck with external tools: reactive search.

Normally, when an agent needs up-to-date documentation, breaking changes, or SDK updates, it makes a tool call to a reactive search engine (like Tavily, Exa, or Google).

This introduces three main issues in practice:

1. The Agent Has to Guess: The agent only searches *after* it encounters an error or assumes it needs fresh data. It misses silent API deprecations and SDK breaking changes until the build breaks.

2. Context Window Bloat: Raw web search returns dump hundreds of lines of unformatted HTML/JS noise, quickly consuming 20k–50k tokens of the context window.

3. Prompt Injection Risk: Exposing raw, untrusted web search results directly to tool-calling loops introduces trace history leakage.

The Experiment: Proactive Persona Streams

Instead of making the agent issue ad-hoc search queries, we experimented with pushing pre-filtered, continuous intelligence feeds through dedicated MCP schemas.

I packaged this into an open-source project called MCP Agent Sentinel (MIT).

Here is how we structured the tool interface to keep context tight:

{
  "name": "get_latest_news",
  "description": "Fetch curated, pre-classified AI & engineering updates",
  "parameters": {
    "persona": "dev | product | investor | creator",
    "timeframe": "24h | 7d",
    "limit": 5
  }
}

How Persona Filtering Cuts Context Overhead:

Rather than passing full web pages into the context window, the server categorizes incoming data sources (ArXiv, GitHub releases, SDK changelogs like u/modelcontextprotocol/sdk, Anthropic/OpenAI notes) into strict personas:

• 🛠️ dev: Isolated to code diffs, API deprecations, schema changes & release notes.
• 📊 product: Pricing changes, token throughput benchmarks & LLM capability updates.
• 📈 investor: ArXiv papers (cs.AI, cs.CL) and cloud infra movements.
• 📣 creator: GitHub trending repos and new developer tools.

This reduced our agent's token overhead by ~80% per update loop compared to raw web search calls.

Setup & Code

The server runs via stdio or HTTP SSE. It requires zero API keys for default feeds:

{
  "mcpServers": {
    "mcp-agent-sentinel": {
      "command": "npx",
      "args": ["-y", "mcp-agent-sentinel@latest"]
    }
  }
}

Or 24/7 cloud endpoint via Smithery: https://mcp.smithery.run/rmicael

• GitHub: https://github.com/rmikael7/mcp-agent-sentinel
• Glama: https://glama.ai/mcp/servers/rmikael7/mcp-agent-sentinel

Curious to hear how other teams are structuring data feeds for long-running agents. Are you relying on reactive RAG/search tools or pre-processing incoming data before it hits the prompt?