---
title: "How Much Tool Documentation Do AI Agents Actually Need?"
description: "Trimming MCP tool-definition prose cut cold-call input tokens 12-14% with no statistically detectable accuracy loss across two model tiers."
author: "Hugues Clouâtre"
pubDatetime: 2026-09-19T15:26:35.000Z
modDatetime: 2026-10-07T19:00:00.000Z
url: https://clouatre.ca/posts/mcp-tool-docs/
tags:
- "agentic-ai"
- "architecture"
- "case-studies"
- "mcp"
---
Multi-agent platforms pay a hidden tax on every request: agent clients serialize the available tool definitions, schemas and description prose included, into the model context before the user's task begins. Catalogs of dozens of tools turn that prose into a recurring line item: billed in tokens on every call, and paid again as degraded attention on every long prompt.
The industry learned this at the prompt level. Anthropic removed over 80% of the Claude Code system prompt with no measurable loss for Opus 5 and Fable 5 ([Shihipar, 2026](https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models)). The unexamined next layer sits one level down: the tool definitions themselves. Anthropic's own tool-use documentation says only that when a required parameter is missing, Opus tends to ask a clarifying question while less capable models may infer a value ([Anthropic, 2026](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview)). Because the documentation offers no evidence either way, teams keep paying for prose rather than risk accuracy on cheaper models.
Two pre-registered experiments tested that premise with 480 blind-scored tool calls across a compact model tier and a frontier one. Trimming tool-level prose and consolidating response-shaping parameters produced no statistically detectable accuracy loss at either tier, while the primary prose trim cut mean cold-call input tokens up to 13.8%. Those are cold-call figures: cached multi-turn sessions read the schema from a discounted prefix, so the dollar saving depends on the cache hit rate while the attention-budget saving applies to every call. The full dataset, including all 480 blind-scored calls and the pre-registered rubric, is openly available ([Clouatre, 2026](https://doi.org/10.5281/zenodo.22844431)). For a CTO weighing model mix, schema prose is a cost lever, and capability spend is the accuracy lever. That accuracy spend keeps shrinking as open-weight models close the structured output quality gap ([Open-Weight LLMs Reach the Structured Output Quality Ceiling](/posts/open-weights-structured-output-cost/)).
## Table of contents
## Why Does Tool Documentation Cost AI Agents So Much?
When [Hasan et al. (2026)](https://arxiv.org/abs/2602.14878) audited 856 tools on 103 MCP servers, 97.1% of tool descriptions carried at least one documentation smell; no published study had measured whether trimming them costs accuracy.
### How Do Verbose Tool Definitions Tax Cost and Quality?
Every descriptive word in an MCP tool definition is serialized into the model's context and consumes budget before the user's question arrives. The Model Context Protocol (MCP), the open standard for connecting AI agents to external tools, exposes tool definitions containing a name, description, and input schema, parameter descriptions included. A server exposing forty tools with verbose documentation can spend thousands of tokens on definitions alone.
The cost compounds through a known failure mode. [Chroma Research (2025)](https://www.trychroma.com/research/context-rot) found that every frontier model tested degrades as input length grows. Longer tool catalogs mean more rot-prone context, so schema bloat taxes both cost and quality.
### Did Anyone Measure Whether Trimming Hurts Accuracy?
The spec's history shows the community guessed at the fix without evidence. SEP-1382 proposed splitting tool-description and param-description roles as a best practice, but the proposal closed dormant for lack of supporting data ([MCP, 2026](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1382)). Practitioners were told which knobs exist, yet nobody had measured whether either knob moves accuracy, or whether the effect depends on model size.
Two further studies frame the gap. A smell-aware rewrite evaluation raised tool-selection odds across 10,831 servers ([Wang et al., 2026](https://arxiv.org/abs/2602.18914)), and Yu et al. (2026) benchmarked tool-call completion on cloud-network APIs. Table 1 summarizes what the published record shows.
*Table 1: Published evidence on tool documentation quality and context cost.*
| Source (Year) | Evidence base | Key finding |
|---------------|---------------|-------------|
| Shihipar (2026) | Claude Code system prompt | Over-80% prompt cut caused no measurable loss, tested on Opus 5 and Fable 5 |
| Chroma Research (2025) | Frontier model suite | Accuracy degrades as input length grows (context rot) |
| Hasan et al. (2026) | 856 tools on 103 MCP servers | 97.1% of tool descriptions contain at least one smell |
| Wang et al. (2026) | 10,831 MCP servers | 73% of servers repeat the tool name; smell-aware rewrites raise selection odds |
| Yu et al. (2026) | ParamBench, cloud-network APIs | Frontier models complete fewer than half of cloud-networking tool calls |
Hasan's gain came from added content, not trimmed prose. None of these studies isolated documentation placement across model sizes; that is the gap this post fills.
## How Did We Test Tool Documentation Trims?
Experiment 1 used a 2x2 ablation on one production MCP server tool, `analyze_symbol`, alongside two distractor tools to keep tool selection honest. Four cells crossed documentation richness at two levels: rich versus lean tool descriptions, each combined with rich versus sparse parameter descriptions (Figure 1). The primary comparison was Cell C, which reflects current production text, against Cell A, a reconstruction of the historical rich baseline. Two models ran the grid: claude-haiku-4-5 and claude-sonnet-5, a compact tier and a frontier tier one generation apart. 8 prompts, 5 runs, 4 cells, 2 models: 320 calls.
```mermaid
%% Diagram of the 2x2 ablation design with four cells crossing rich and lean tool descriptions against rich and sparse param descriptions
graph TD
classDef primary fill:#075985,stroke:#282728,stroke-width:2px,color:#fff
classDef secondary fill:#e6e6e6,stroke:#ece9e9,stroke-width:2px,color:#282728
classDef accent fill:#38bdf8,stroke:#075985,stroke-width:2px,color:#fff
classDef muted fill:#fdfdfd,stroke:#ece9e9,stroke-width:1px,color:#282728
linkStyle default stroke-width:3px
A["Cell A
Rich + Rich"]:::primary
B["Cell B
Rich + Sparse"]:::secondary
C["Cell C
Lean + Rich"]:::secondary
D["Cell D
Lean + Lean"]:::muted
ROOT["Experiment 1
2x2 Ablation"]:::accent
ROOT --> A
ROOT --> B
ROOT --> C
ROOT --> D
```
*Figure 1: Experiment 1's 2x2 ablation grid. Each cell combines a tool-description level with a param-description level; Cell C versus Cell A isolates the tool-level trim against the richest baseline.*
Every response was blind-scored against a pre-registered rubric ([Clouatre, 2026](https://doi.org/10.5281/zenodo.22844431)). Results were tested with two-tailed Mann-Whitney U at alpha 0.05, a rank-based test that makes no normality assumption and suits ordinal rubric scores. Input tokens were logged per call, giving a paired cost measurement alongside accuracy.
Experiment 2 probed structure rather than prose. It collapsed four response-shaping parameters into a single `response_format` enum, running 160 calls under the same protocol, prompts, and models. The question: does consolidating parameters into structural choice preserve accuracy while trimming tokens? Four separate boolean and string parameters became one enumerated option, shrinking both the parameter list and the prose describing each option (Code Snippet 1).
*Code Snippet 1: The response-shaping interface before and after the Experiment 2 treatment: four parameters in the control arm, one bounded enum in the treatment arm.*
```json {11} file="response-format-collapse.json"
[
{
"arm": "control",
"response_format": {
"summary": true,
"fields": ["functions"],
"mode": "callgraph",
"implOnly": false
}
},
{ "arm": "treatment", "response_format": "functions" }
]
```
## What Did 480 Blind-Scored Tool Calls Show?
Cell C versus Cell A on param-fill score gave p=0.372 for Haiku (U=720, r=0.10) and p=0.569 for Sonnet (U=820, r=-0.025): accuracy statistically comparable at both tiers. A finer check-level composite score matched, at p=0.504 and p=0.569 respectively. The only wrinkle was Cell D, the fully lean cell, which degraded the compact tier's param-fill score; the frontier tier held.
*Table 2: Outcomes for both experiments by model tier. Experiment 1 compares Cell C with Cell A (tool-description trim); Experiment 2 compares four response-shaping parameters with one enum. No comparison reached significance; tokens fell in every case.*
| Model tier | Exp 1: param-fill p | Exp 1: composite p | Exp 1: input tokens | Exp 2: accuracy p | Exp 2: input tokens |
|------------|---------------------|--------------------|---------------------|-------------------|---------------------|
| Haiku | 0.372 | 0.504 | -12.4% | 0.335 | -3.3% |
| Sonnet | 0.569 | 0.569 | -13.8% | 0.242 | -4.3% |
### How Much Did the Prose Trim Save in Input Tokens?
Mean input tokens fell 12.4% on Haiku and 13.8% on Sonnet. The top-level description fell from 1,856 to 465 characters, a 75% cut; across the full serialized tool definition, the measured prompt contribution fell roughly 45%.
**Lean descriptions cut cold-call tokens at both tiers**
| Series | Cell A | Cell B | Cell C | Cell D |
| --- | --- | --- | --- | --- |
| Haiku mean | 2625 (95% CI 2622.4-2627.6) | 2337 (95% CI 2334.4-2339.5) | 2299 (95% CI 2296.4-2301.6) | 2011 (95% CI 2008.5-2013.5) |
| Sonnet mean | 3319.125 (95% CI 3315.5-3322.8) | 2911.125 (95% CI 2907.4-2914.8) | 2860.125 (95% CI 2856.4-2863.8) | 2452.125 (95% CI 2448.4-2455.9) |
- Haiku observations 1/4 (n=40): 2613, 2613, 2613, 2613, 2613, 2614, 2614, 2614, 2614, 2614, 2622, 2622, 2622, 2622, 2622, 2623, 2623, 2623, 2623, 2623, 2625, 2625, 2625, 2625, 2625, 2633, 2633, 2633, 2633, 2633, 2633, 2633, 2633, 2633, 2633, 2637, 2637, 2637, 2637, 2637
- Haiku observations 2/4 (n=40): 2325, 2325, 2325, 2325, 2325, 2326, 2326, 2326, 2326, 2326, 2334, 2334, 2334, 2334, 2334, 2335, 2335, 2335, 2335, 2335, 2337, 2337, 2337, 2337, 2337, 2345, 2345, 2345, 2345, 2345, 2345, 2345, 2345, 2345, 2345, 2349, 2349, 2349, 2349, 2349
- Haiku observations 3/4 (n=40): 2287, 2287, 2287, 2287, 2287, 2288, 2288, 2288, 2288, 2288, 2296, 2296, 2296, 2296, 2296, 2297, 2297, 2297, 2297, 2297, 2299, 2299, 2299, 2299, 2299, 2307, 2307, 2307, 2307, 2307, 2307, 2307, 2307, 2307, 2307, 2311, 2311, 2311, 2311, 2311
- Haiku observations 4/4 (n=40): 1999, 1999, 1999, 1999, 1999, 2000, 2000, 2000, 2000, 2000, 2008, 2008, 2008, 2008, 2008, 2009, 2009, 2009, 2009, 2009, 2011, 2011, 2011, 2011, 2011, 2019, 2019, 2019, 2019, 2019, 2019, 2019, 2019, 2019, 2019, 2023, 2023, 2023, 2023, 2023
- Sonnet observations 1/4 (n=40): 3303, 3303, 3303, 3303, 3303, 3304, 3304, 3304, 3304, 3304, 3313, 3313, 3313, 3313, 3313, 3313, 3313, 3313, 3313, 3313, 3326, 3326, 3326, 3326, 3326, 3327, 3327, 3327, 3327, 3327, 3328, 3328, 3328, 3328, 3328, 3339, 3339, 3339, 3339, 3339
- Sonnet observations 2/4 (n=40): 2895, 2895, 2895, 2895, 2895, 2896, 2896, 2896, 2896, 2896, 2905, 2905, 2905, 2905, 2905, 2905, 2905, 2905, 2905, 2905, 2918, 2918, 2918, 2918, 2918, 2919, 2919, 2919, 2919, 2919, 2920, 2920, 2920, 2920, 2920, 2931, 2931, 2931, 2931, 2931
- Sonnet observations 3/4 (n=40): 2844, 2844, 2844, 2844, 2844, 2845, 2845, 2845, 2845, 2845, 2854, 2854, 2854, 2854, 2854, 2854, 2854, 2854, 2854, 2854, 2867, 2867, 2867, 2867, 2867, 2868, 2868, 2868, 2868, 2868, 2869, 2869, 2869, 2869, 2869, 2880, 2880, 2880, 2880, 2880
- Sonnet observations 4/4 (n=40): 2436, 2436, 2436, 2436, 2436, 2437, 2437, 2437, 2437, 2437, 2446, 2446, 2446, 2446, 2446, 2446, 2446, 2446, 2446, 2446, 2459, 2459, 2459, 2459, 2459, 2460, 2460, 2460, 2460, 2460, 2461, 2461, 2461, 2461, 2461, 2472, 2472, 2472, 2472, 2472
*Figure 2: Input tokens per call by cell in Experiment 1; dots are individual calls (320 total), lines track each model's mean with bootstrap 95% CIs. Tokens fall monotonically as documentation gets leaner: the Cell C vs A trim saves 12.4% (Haiku) and 13.8% (Sonnet), and the fully lean Cell D saves 23.4% and 26.1%.*
Experiment 2 matched the pattern (Table 2). The four parameters encoded a small set of valid response modes, and the enum covered every supported combination, so the savings came from structure, not lost function.
```mermaid
%% Diagram of experiment 2's two arms, control with four parameters versus treatment with a single enum
graph TD
classDef primary fill:#075985,stroke:#282728,stroke-width:2px,color:#fff
classDef secondary fill:#e6e6e6,stroke:#ece9e9,stroke-width:2px,color:#282728
classDef accent fill:#38bdf8,stroke:#075985,stroke-width:2px,color:#fff
classDef muted fill:#fdfdfd,stroke:#ece9e9,stroke-width:1px,color:#282728
linkStyle default stroke-width:3px
ROOT["Experiment 2
Response Format"]:::accent
ARM1["Control Arm
Four Parameters"]:::primary
ARM2["Treatment Arm
Single Enum"]:::secondary
ROOT --> ARM1
ROOT --> ARM2
ARM1 --> R1["Baseline
Tokens"]:::muted
ARM2 --> R2["3.3-4.3%
Token Savings"]:::muted
```
*Figure 3: Experiment 2's two arms under identical prompts and models, with four response-shaping parameters collapsed into one enum in the treatment arm.*
### What Mattered More Than Documentation Richness?
In this workload, the observed gap between model tiers was larger than the observed effect of documentation richness. Sonnet sat near ceiling, with mean param-fill scores of 0.825 to 0.975 in every cell. Haiku stayed uniformly weaker at 0.475 to 0.625 across every cell, meaning its failures tracked capability limits. Tool-selection accuracy was equally flat: 0.575 to 0.6 for Haiku and 0.95 to 0.975 for Sonnet in every cell, so the trim moved neither filling nor selection.
Hours spent polishing tool descriptions to rescue a small model target the wrong lever; prompt design, validation layers, or escalation to a larger model target the gap the data shows.
:::note
Each cell held n=40 calls: the study rules out large regressions on this workload but remains underpowered to exclude small accuracy effects, especially given Sonnet's score ceiling. Experiment 2's post-hoc sensitivity analysis, dropping one trap check, flips direction for Sonnet at p=0.0427; that result is explicitly exploratory and carries multiple-comparisons risk. Cell A is a reconstruction, not literal historical text. Token figures are cold-call measurements. Finally, the results characterize one production tool deeply, not a broad tool catalog.
:::
## What Does Leaner Tool Documentation Unlock Next?
The results suggest that, for this workload, retained parameter semantics and schema structure were sufficient once broad tool-level prose was trimmed. That points toward two architecture questions beyond schema hygiene. The first targets the schema payload itself. If lean manifests and on-demand tool inspection preserve selection and execution quality in a given workload, an agent may not need the full tool catalog in every model request: it can inspect tool APIs dynamically inside an isolated runtime and generate deterministic scripts that call them. The catalog becomes a cache, fetched on demand, and the same question now extends to the public web, where [Agent-Ready Websites: The 5-Layer Implementation Stack](/posts/agent-ready-website/) maps what sites should expose to agents. A follow-up, [Does WebMCP Pay Off for Content Sites?](/posts/webmcp-beyond-checkout/), tests that question on this site's in-browser tools.
Security teams should note the trade: script generation moves risk from context injection into execution, making sandboxing, capability-scoped credentials, egress controls, and audit trails first-class design requirements. Security testing of agents at Google and five other organizations turned injected tool output into cross-agent request forgery, patched per implementation as CVE-2026-14540 ([Goodin, 2026](https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/)). The MCP specification responds by requiring clients to treat tool descriptions and annotations as untrusted data ([MCP, 2026](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). Injected content arrives as tool output, the channel dynamic catalogs fetch on demand.
The protocol work to support this is underway. Tool manifests for incremental catalog synchronization, proposed in PR 2636, let clients sync catalogs without re-sending full definitions ([MCP, 2026](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2636)). Routing economics reinforce the case ([Dekoninck et al., 2024](https://arxiv.org/abs/2406.18665)): a cheap model handles routing and extraction, and a frontier model takes only what is genuinely ambiguous.
## Where Do Small Models Fit in the Tool Layer?
Haiku's lower but structured profile motivates testing compact models on narrowly bounded, verifiable subtasks such as routing and extraction, paired with validation and escalation to frontier models for ambiguous planning. This study does not establish that a compact model can safely own those tasks across a broad production catalog.
Typed-judgment systems make this concrete: TypeSafe's System One models return typed answers with probabilities that ordinary code composes into pipelines ([TypeSafe, 2026](https://docs.typesafe.ai/concepts/system-one)). Its [re-ranking cookbook](https://docs.typesafe.ai/cookbooks/rerank_typesafe) shows a small model with the right output contract beating a larger one. Tool routing, with a bounded enum of choices, fits that pattern closely.
Early commercial infrastructure exposes this shape. OpenRouter's alpha decisions endpoint accepts typed questions, boolean (`noul`), choice, or score, and serves them through TypeSafe's Jev, the first commercially hosted decision model of this kind; TypeSafe's own API offers the same contract first-party ([OpenRouter, 2026](https://openrouter.ai/docs/api/api-reference/alphadecisions/submit-a-decisions-questions-and-answers-request)). OpenAI followed at DevDay 2026 with a Decisions API built on a specialized GPT-6 Luna, in limited preview as of this writing ([Firecrawl, 2026](https://www.firecrawl.dev/blog/openai-decisions-api-vs-jev)). Two commercial vendors and an active open-weights field now back the same shape:
*Code Snippet 2: A typed-decision request against OpenRouter's alpha decisions endpoint. Each question carries an explicit type and bounded criteria, no prose negotiation required.*
```json file="alpha-decisions-request.json"
{
"model": "typesafe/jev-1.13",
"questions": {
"is_bug": {
"type": "noul", // [!code highlight]
"instructions": "Is the customer reporting a software defect?"
},
"urgency": {
"type": "score",
"criteria": ["Can wait", "Fix this week", "Blocking revenue"]
}
},
"state": { "ticket": "Checkout page is blank after Pay." }
}
```
*Table 3: External evidence on small-model routing with typed output contracts.*
| Source (Year) | What was measured | Result |
|---------------|-------------------|--------|
| TypeSafe (2026) | Typed re-rank contract, legal retrieval | Top-1 retrieval 5% to 18% |
| Dekoninck et al. (2024) | RouteLLM routing economics | Frontier-level quality at a fraction of the cost |
| Yu et al. (2026) | Probe-guided training plus re-rank, cloud-network APIs | Exact match 19.7% to 59.6%, five open-source models |
| Layer3Labs (2026) | Independent head-to-head: open-weights Kev vs Jev | Accuracy within 1.5 points (93.9-98.3% vs 95.1-97.5%) |
```mermaid
%% Diagram of a forward architecture combining lean tool manifests, code-driven execution in an isolated runtime, and a small-model tool-layer cascade with frontier escalation
graph TD
classDef primary fill:#075985,stroke:#282728,stroke-width:2px,color:#fff
classDef secondary fill:#e6e6e6,stroke:#ece9e9,stroke-width:2px,color:#282728
classDef accent fill:#38bdf8,stroke:#075985,stroke-width:2px,color:#fff
classDef muted fill:#fdfdfd,stroke:#ece9e9,stroke-width:1px,color:#282728
linkStyle default stroke-width:3px
REQ["Agent
Request"]:::accent
CAT["Lean Tool
Manifest"]:::primary
RUN["Isolated
Runtime"]:::primary
SM["Small Model
Tool Layer"]:::secondary
FM["Frontier Model
Ambiguous Planning"]:::secondary
SCRIPT["Deterministic
Scripts"]:::muted
REQ --> CAT
CAT --> SM
SM --> RUN
SM --> FM
RUN --> SCRIPT
SCRIPT --> REQ
```
*Figure 4: Target tool-layer architecture. A compact model selects against lean manifests synced incrementally; an isolated runtime executes deterministic scripts; ambiguous planning escalates to a frontier model.*
This is a direction of travel; the experiments here do not test the composition, and each piece needs its own security and reliability evaluation. Structurally, the cascade is propose/validate: a small model proposes the routing decision, escalation validates it. Because the typed-decision contract is now a product category and open-weights models match the hosted model's accuracy within 1.5 points, the proposal step no longer requires building a custom judge.
## What Should Platform Teams Do?
The immediate move is editorial. Trimming description strings now is supported by the direct finding: the production trim cut the `analyze_symbol` description from 1,856 to 465 characters, and input tokens fell 12-14% on cold calls with no statistically detectable accuracy loss at two model tiers. The change requires no runtime work and compounds across every entry in the catalog.
*Code Snippet 3: The trim pattern the data supports: one-line tool purpose, correctness constraint beside the parameter it governs, bounded choices as enums.*
```json file="lean-tool-definition.json"
[
{
"name": "deploy_service",
"description": "Deploy a service to a target environment.",
"inputSchema": {
"type": "object",
"properties": {
"env": {
"type": "string",
"enum": ["staging", "prod"], // [!code highlight]
"description": "Target environment. Use prod only when approved."
},
"ref": {
"type": "string",
"description": "Git ref to deploy; defaults to main."
}
},
"required": ["env"]
}
}
]
```
The rule the snippet encodes: if a constraint matters for correctness, express it where the parameter is defined, not in tool-level prose. Parameter semantics carried the load in these experiments; vague tool-level narrative did not.
## How Do You Estimate the Monthly Token Savings?
Before rolling a trim out widely, measure with your own prompts; a day of pre-registered scoring on a real workload buys confidence the literature cannot. When reading the token numbers, treat them as a cold-call ceiling for the cost benefit: cached multi-turn sessions read the schema from a discounted prefix. The attention benefit does not amortize. For a monthly estimate, weight the token cut by the cold/warm split and apply your provider's cache-read discount (0.1x on some plans):
*Code Snippet 4: Monthly savings as a cache-weighted blend of cold and warm calls.*
```python file="savings-formula.py"
def monthly_savings(n_calls, input_cost, p_cold, d_cache):
return n_calls * input_cost * ( # [!code highlight]
p_cold * delta_cold
+ d_cache * (1 - p_cold) * delta_warm
)
```
Where `n_calls` is tool-enabled calls per month, `input_cost` the baseline per-call input cost used for a planning estimate (mean input tokens times price; apply the cache multiplier only to the provider-defined cacheable prefix for precise billing forecasts), and `p_cold` the fraction of calls without a cache hit. `delta_cold` is the measured fractional cold-call cut, 0.124 to 0.138; `delta_warm` is the fractional reduction in the cacheable warm prefix, and `d_cache` is your provider's cache-read price multiplier, 0.1 on some plans but model- and billing-specific; verify it for your deployment. Every turn still pays full price in context budget, and the context-rot decay documented earlier grows with input length, so shorter catalogs leave more room before it arrives.
## Takeaways
1. **Trimming showed no detectable accuracy loss at either tier.** Lean production text matched the rich baseline (p=0.372, p=0.569, primary comparison).
2. **Trimming paid in tokens.** Mean input tokens fell 12.4% on Haiku and 13.8% on Sonnet on cold calls.
3. **Model tier mattered more than documentation richness.** In this workload, the observed capability gap dwarfed any documentation effect.
4. **Structure consolidations compound the savings.** Collapsing four parameters into one enum saved 3.3-4.3% more tokens with accuracy statistically comparable at both tiers.
5. **The next shrink target is the catalog itself.** Code-driven execution against synced manifests, per PR 2636, creates a testable path to smaller tool payloads, a composition the experiments here did not evaluate.
6. **Small models are candidates for bounded tool-layer tasks.** Typed contracts, validation, and escalation can make compact models economically attractive for narrowly scoped decisions; two commercial vendors now expose the contract, and an open-weights model independently matches the hosted leader within 1.5 points.
## References
- Anthropic, "Tool use overview" (2026) -- https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- Chroma Research, "Context Rot" (2025) -- https://www.trychroma.com/research/context-rot
- Clouatre, H., "MCP Parameter-Description Ablation" (2026) -- https://doi.org/10.5281/zenodo.22844431
- Dekoninck, J., et al., "RouteLLM: Learning to Route LLMs with Preference Data" (2024) -- https://arxiv.org/abs/2406.18665
- Firecrawl, "OpenAI's Decisions API vs Jev: Inside the Decision-Model Architecture" (2026) -- https://www.firecrawl.dev/blog/openai-decisions-api-vs-jev
- Goodin, D., "Vulnerability in agents from Google and others exposes structural flaw in MCP" (2026) -- https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/
- Hasan, M. M., et al., "Model Context Protocol (MCP) Tool Descriptions Are Smelly! Towards Improving AI Agent Efficiency with Augmented MCP Tool Descriptions" (2026) -- https://arxiv.org/abs/2602.14878
- Layer3Labs, "AI Decision Models: Jev, Laya, and Open Alternatives" (2026) -- https://www.layer3labs.io/guides/system-one-decision-models
- MCP, "Security and Trust & Safety" specification section, version 2026-07-28 (2026) -- https://modelcontextprotocol.io/specification/2026-07-28/server/tools
- MCP, SEP-1382 "Split Tool-Description and Param-Description Roles" (2026) -- https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1382
- MCP, PR 2636 "Tool Manifests for Incremental Catalog Synchronization" (2026) -- https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2636
- OpenRouter, "alpha.decisions: Submit a Decisions (questions and answers) request" (2026) -- https://openrouter.ai/docs/api/api-reference/alphadecisions/submit-a-decisions-questions-and-answers-request
- Shihipar, A., "The new rules of context engineering for Claude 5 generation models" (2026) -- https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
- TypeSafe, "Re-ranking with TypeSafe" cookbook (2026) -- https://docs.typesafe.ai/cookbooks/rerank_typesafe
- TypeSafe, "System One" docs (2026) -- https://docs.typesafe.ai/concepts/system-one
- Wang, P., et al., "From Docs to Descriptions: Smell-Aware Evaluation of MCP Server Descriptions" (2026) -- https://arxiv.org/abs/2602.18914
- Yu, G., et al., "Getting the Parameters Right: A Difficulty-Graded Benchmark and Probe-Guided Training for LLM Tool Calls" (2026) -- https://arxiv.org/abs/2608.03071