Fetching from the wire…
01
02
03
04
05
06
07
08
Top 5 · 2026-06-21 · source-backed
This is the most useful engineering thing I read all week, and it's not a model. It's a pattern. Anthropic's engineering post on code execution with MCP describes laying out MCP tools as files in a code tree (think ./servers/google-drive/getDocument.ts) that the agent discovers by browsing and reads on demand, instead of loading every tool definition into context upfront. In their Google Drive to Salesforce example, that took a task from 150K tokens to 2K. A 98.7% cut.
If you've built anything serious with MCP, you've felt this pain. Every connected server dumps its full tool schema into the context window before the agent does a single thing. Connect a dozen servers and you've spent tens of thousands of tokens on definitions the agent will never touch this turn. It's the dumbest tax in agent engineering and almost everyone is paying it.
The fix is search-first. The New Stack reports the same idea from the other direction: replace static tool catalogs with 2-3 lightweight meta-tools that fetch full schemas on demand, and benchmarks show up to 160x fewer tokens at 100% task success. Cloudflare compressed 2,500 API endpoints into 2 tools for a 99.9% reduction. The other half of the trick is keeping intermediate data inside the execution environment so it never round-trips through the model's context at all.
The part I'll actually steal: pairing this with a ./skills/ directory and SKILL.md files so working implementations persist as a reusable toolbox across sessions. That's the bridge between "agent figures it out every time" and "agent has a standard library." My own pipeline centralizes tool definitions in a way that's exactly the antipattern here, and I'm refactoring it this week.
If you run more than two or three MCP servers, this isn't an optimization. It's the difference between an agent that can afford to think and one that spends its whole budget reading menus. Also default your tool results to small pages, 10-20 items with a has_more flag, so the agent chooses when to fetch more instead of you dumping the whole result set.
Each link below shares sources, entities, or timing with this story.
Cloudflare supports MCP / Shared entities / Shared topic / Earlier coverage / Tension
Linked by a graph relationship (Cloudflare supports MCP); both cover Anthropic, MCP, Skill; overlapping topics (agent, code, context, server, token).
Atlassian criticizes Salesforce / Shared entities / Same source domain / Shared topic / Earlier coverage
Linked by a graph relationship (Atlassian criticizes Salesforce); both cover Anthropic, Cloudflare, SKILL; reported by the same outlet (anthropic.com).
Claude Opus built by Anthropic / Shared entities / Same source domain / Shared topic / Earlier coverage / Tension
Linked by a graph relationship (Claude Opus built by Anthropic); both cover Anthropic, Connect; reported by the same outlet (anthropic.com).
Salesforce acquired Intercom / Shared entities / Shared topic / What happened next / Tension
Linked by a graph relationship (Salesforce acquired Intercom); both cover Anthropic, Connect, Salesforce; overlapping topics (model, token).
Cloudflare supports MCP / Shared entities / Shared topic / Earlier coverage
Linked by a graph relationship (Cloudflare supports MCP); both cover Cloudflare, MCP; overlapping topics (agent, code, context, definition, token).
Cloudflare supports MCP / Shared entities / Same source domain / Shared topic / Earlier coverage
Linked by a graph relationship (Cloudflare supports MCP); both cover Anthropic, MCP; reported by the same outlet (anthropic.com).
Cloudflare supports MCP / Shared entities / Shared topic / Earlier coverage
Linked by a graph relationship (Cloudflare supports MCP); both cover Cloudflare, MCP; overlapping topics (agent, code, definition, server, token).
Linked by a graph relationship (Cloudflare supports MCP); both cover Anthropic, Connect, MCP; overlapping topics (agent, code, model).