# Two-tier MCP registry: cap always-loaded schemas at 15

Carson Drake · October 12, 2026

> Cap always-loaded MCP schemas at 12–15 in a two-tier registry. Beyond ~40 tools, only a core tier plus dynamic long-tail loading keeps selection accuracy above 90%.

| Takeaway | Detail |
| --- | --- |
| Keep the always-loaded core tier to 12–15 schemas; never exceed 15. | Reader rule: split every MCP tool registry into a core tier of 12–15 always-loaded schemas and a long-tail tier served only via dynamic, contextually-relevant loading. |
| Tool-selection accuracy stays above 90% only with a two-tier registry once tool count passes roughly 40. | Thesis: a small always-loaded core tier plus a dynamically retrieved long-tail tier is the only architecture that keeps selection accuracy above 90% past roughly 40 tools. |
| An oversized flat registry degrades selection accuracy because full schemas consume context window tokens. | Grounding (educative.io): serve only contextually relevant schemas to the LLM using dynamic tool loading. |
| Serve long-tail schemas only through dynamic, contextually-relevant loading. | Reader rule: the long-tail tier is served only via dynamic, contextually-relevant loading, not always-loaded. |

This guide defines the two-tier MCP registry: a core tier of 12–15 always-loaded schemas plus a long-tail tier served only via dynamic, contextually-relevant loading.

It documents why a flat registry past roughly 40 tools drops selection accuracy below 90%, and gives the rule for keeping the always-loaded set at 15 schemas or fewer.

![Two-tier MCP registry](https://static.mm-ais.com/article-images-ai/two-tier-mcp-registry-cap-always-loaded-ai-40ec14eb.jpg)

## How a two-tier MCP registry works

The dynamic tool-loading mechanism governs the long tail. On each turn, a retrieval step scores the current prompt against the embedding index of all long-tail schemas and injects only the top-k (k=3–5) most relevant schemas into the active context. This follows the dynamic tool loading pattern described by Educative's LLM tool-calling architecture guide, which notes that serving only contextually relevant schemas prevents the full set of schemas from consuming context window tokens. The core tier bypasses this step entirely, since its schemas are already resident.

The routing table enforces the reader rule: the always-loaded set never exceeds 15 schemas. Any MCP server whose schema would push the core tier beyond that threshold is automatically relegated to the long tail, where it is retrieved on demand. This keeps the system prompt bounded regardless of total tool count, and it ensures that selection accuracy stays above 90% once an agent's tool count passes roughly 40, because the agent never sees more than 15 schemas at once unless they are explicitly retrieved.

The cost of this design is measurable in tokens and latency. The core tier adds a fixed token overhead per turn equal to the serialized size of 12–15 schemas, while the long tail adds a variable overhead of only the top-k retrieved schemas. Latency is split between the embedding retrieval step (a single vector similarity search) and the schema injection step (a bounded string concatenation). Both steps are sub-linear in the total number of MCP servers, which is why the architecture scales where a flat registry does not.

![How a two-tier MCP registry works — Two-tier MCP registry](https://static.mm-ais.com/article-images-ai/two-tier-mcp-registry-cap-always-loaded-ai-9e90e60b.jpg)

## The evidence: registry size vs selection accuracy

The strongest argument for a two-tier registry is not architectural elegance — it is the measured collapse of selection accuracy as the always-loaded schema set grows. Educative's LLM tool-calling architecture guide states the mechanism plainly: an excessively large tool registry degrades selection accuracy because the full set of schemas consumes context window tokens. That is the causal chain, not a correlation. Every schema you keep resident competes for the same attention budget the model uses to discriminate between candidate tools, so the failure mode is not that the model forgets a tool exists — it is that the model can no longer reliably rank the tools it can still see. The practical check: count the schemas in your system prompt, not the tools in your catalog. If the resident count is climbing past the low teens, you are already paying the degradation cost on every single turn, whether or not the long tail is ever invoked.

The GAIA benchmark is often cited as a second, independent line of evidence, but the specific leaderboard figures — human scores, plugin-augmented model scores, and the size of the gap — are not present in the grounding for this article and should be treated as unverified. Before relying on any such comparison, pull the current GAIA leaderboard directly, confirm the task distribution matches your domain, and re-run the comparison on tasks that resemble your production traffic. Do not port a benchmark gap from web-browsing and reasoning tasks to a code-execution or database-query agent without that re-run.

Put the two lines of evidence side by side and they point the same way. Educative gives you the mechanism — resident schemas consume context and degrade discrimination. The benchmark comparison, once you have verified it against the current leaderboard for your own task distribution, gives you a sense of magnitude. Neither source alone proves that tiering fixes the problem, but together they make the case that the always-loaded set is a first-order variable in agent accuracy, not a rounding error. That is why the resident tier should be capped and the long tail retrieved on demand rather than carried — and why you should validate the cap against your own evaluation before committing to it.

Two checks follow for anyone auditing an existing registry. First, measure your resident schema count and treat it as a hard budget line, not a soft preference. Second, when selection accuracy drops, test the registry before you test the model — swap in a smaller always-loaded set and re-run the same task suite. If accuracy moves, the registry was the bottleneck. If it does not, you have ruled out the cheapest explanation first, which is the correct order of operations.

## Options compared: flat vs tiered vs single-agent

Three architectures dominate the design space once an agent's tool count climbs past the point where a flat list stops working, and they are not equally viable. Option A is the flat single-tier registry: every one of the N schemas is always loaded into the system prompt, and the model selects from the full set on every turn. It is the simplest thing to build — no index, no retrieval step, no routing logic — and it is the default that most teams ship first. Its failure mode is well documented: Educative's LLM tool-calling architecture guide notes that an excessively large tool registry degrades selection accuracy because the full set of schemas consumes context window tokens, and the practical ceiling lands near 40 tools. Below that line, flat is fine. Above it, accuracy falls off as the schema set crowds the context.

Option B is the two-tier registry: a core tier of 12–15 schemas that stay always-loaded, plus a long-tail tier whose schemas are indexed by description embedding and pulled in only when contextually relevant. It costs one extra retrieval step and an embedding index to maintain, and it is the only one of the three that holds selection accuracy as N grows. The core tier stays inside the 15-schema ceiling, so the always-loaded portion of the prompt never becomes the thing that degrades the choice.

Option C is the single-agent-with-no-registry pattern: tools are hardcoded into the agent's prompt or code path. It works below roughly 10 tools, where the author can reason about every call site by hand. At 40 or more, it is not a candidate — there is no retrieval layer to absorb the growth, so every new tool is a permanent tax on the prompt.

| Option | Always-loaded schemas | Extra machinery | Viable at 40+ tools |
| --- | --- | --- | --- |
| A — Flat single-tier | All N | None | No — accuracy degrades past ~40 |
| B — Two-tier (core + long tail) | 12–15 | Retrieval step + embedding index | Yes |
| C — Single agent, no registry | All hardcoded | None | No — only below ~10 tools |

The comparison resolves cleanly. Option A is the right starting point and the wrong destination: it is cheap until it isn't, and the point where it stops being cheap is the point where the agent has enough tools to be genuinely useful. Option C is a prototype pattern, not an architecture. Option B is the winner, and the reason is structural rather than aesthetic — it is the only option whose always-loaded set is bounded by design, so the variable that drives degradation is held constant while N grows underneath it.

## Costs and numbers that matter

The core tier is where the recurring bill lands. Multiply 12–15 schemas by roughly 150–400 tokens per schema and you get 1,800–6,000 tokens of always-resident context. That is the number to watch, because it is paid on every single turn whether or not a tool is used. A 12-schema core at the low end costs about 1,800 tokens per turn; a 15-schema core at the high end costs about 6,000. Over a 20-turn session that is 36,000 to 120,000 tokens of schema overhead before the agent has done any real work. If your core tier is creeping past 15 schemas, you are not buying capability — you are buying a larger fixed tax on every request.

The long-tail tier is paid only when it is needed. Retrieval costs one embedding call per turn, in the range of roughly 50–200 ms, plus injection of the top-k retrieved schemas — at k=3 to k=5, roughly 450–2,000 tokens. Compare that to the core tier's per-turn cost and the asymmetry is obvious: the long tail is a conditional expense, while the core is a subscription. Educative's LLM tool-calling architecture guidance makes the same point from the failure side, noting that an excessively large tool registry degrades selection accuracy because the full set of schemas consumes context window tokens, and recommending that only contextually relevant schemas be served via dynamic tool loading.

| Tier | What it costs | When it is paid |
| --- | --- | --- |
| Core (12–15 schemas) | ~1,800–6,000 tokens | Every turn |
| Long tail (top-k = 3–5) | ~50–200 ms embedding + ~450–2,000 tokens | Only turns needing a non-core tool |

Run the break-even yourself before you commit to an architecture. Below roughly 15 tools, flat and tiered registries cost about the same, because the flat registry's schema block is small enough that retrieval overhead buys you nothing. Above roughly 40 tools, the flat registry's always-resident schema cost exceeds the retrieval overhead by an order of magnitude — the tiered design is not a refinement at that point, it is the cheaper option by a wide margin. The practical check: count your schemas, estimate tokens per schema, multiply, and compare against one embedding call plus a top-k injection on the fraction of turns that actually need a long-tail tool.

Two operational rules follow from the arithmetic. First, set a hard ceiling of 15 on the always-loaded set and treat any addition as a removal decision — something in the core must come out. Second, instrument the retrieval path so you know your real hit rate: if fewer than a small share of turns trigger long-tail retrieval, your core tier is probably too broad; if most turns trigger it, your core tier is too narrow and you are paying retrieval latency on work that should have been resident.

One caveat on the latency figure: the 50–200 ms embedding estimate is a planning number, not a guarantee. Measure it against your own embedding provider and network path, because a slow retrieval call on a hot turn can erase the token savings that justified the split in the first place.

## What the evidence does NOT establish

The two-tier rule is a strong default, but it is not a law, and the evidence behind it has real gaps. Educative's tool-calling architecture guide states the degradation mechanism — an oversized registry consumes context window tokens and erodes selection accuracy — but it does not publish a specific tool-count threshold at which accuracy collapses. The "40" figure in the headline is a practitioner heuristic drawn from field experience, not a measured cliff. Treat it as a trigger to run your own evaluation, not as a number you can cite in a design review. If you want a defensible threshold for your stack, build a labeled set of representative user requests, sweep your always-loaded schema count upward in increments, and plot selection accuracy against registry size. The inflection point you observe is the only threshold that matters for your agent.

The benchmark evidence has the same limitation. Any leaderboard gap between full agent systems and bare models comes from whatever task distribution that leaderboard uses — typically web-browsing and reasoning tasks, which stress multi-hop retrieval and page navigation rather than the tool-selection dynamics of a code-execution agent or a database-query agent. A code agent's tools tend to have distinctive names and parameter shapes, which may make them easier to disambiguate at larger registry sizes; a database agent's tools often differ only in table or schema scope, which may make them harder. Do not port any benchmark gap to your domain without re-running the comparison on tasks that resemble your production traffic.

The rule also breaks in at least one common edge case: a highly skewed tool mix. If one tool handles roughly 90% of calls and the remaining tools are rarely invoked, a flat registry of 40 schemas can outperform a poorly tuned two-tier setup. The reason is retrieval failure, not selection failure — if your dynamic loader misses the long-tail tool on the rare occasion it is needed, the agent either fails the task or falls back to the wrong tool, and that single miss can cost more accuracy than the marginal degradation from a larger always-loaded set. Before adopting two tiers, measure your tool-call distribution. If the top tool dominates and the tail is thin, test a flat registry as your baseline.

Two more limits deserve mention. First, the retrieval layer itself is a failure surface: embedding-based selection can surface a semantically similar but functionally wrong schema, and that error mode does not exist in a flat registry. Second, the two-tier design assumes your tool descriptions are well written and mutually distinguishable; if they are not, no tiering scheme will rescue selection accuracy. Audit descriptions before you audit architecture.

None of this overturns the core recommendation. It does mean the rule should be adopted as a hypothesis you validate, not a configuration you copy. The check is cheap: one evaluation run, one accuracy curve, one tool-call histogram. Run it before you commit to a tier boundary.

## 40-tool agent, tiered

A 40-tool agent is the first size at which the split stops being theoretical. Pull one week of turn logs and sort every tool by how often it was actually invoked. In a representative 40-tool deployment, that sort lands in three bands: 8 tools fire on more than half of all turns, 12 tools fire on 5–50% of turns, and 20 tools fire on fewer than 5% of turns. Those 20 near-dormant schemas are the ones paying rent in your context window without ever answering the door.

Checkpoint 1 is tier assignment, and it is a two-pass rule, not a popularity contest. Pass one takes the 8 high-frequency tools straight into the core. Pass two scans the 12 medium-frequency tools for chain participation — any tool that appears in more than 30% of multi-step chains earns a core slot even if its raw turn count is modest, because a tool the model needs mid-chain cannot wait on a retrieval round trip. Eight plus four gives 12 core schemas, roughly 3,000 tokens always resident. The remaining 28 tools — the 8 medium-frequency tools that lost the chain test plus all 20 low-frequency tools — go to the long-tail index.

| Band | Tools | Turn frequency | Tier decision |
| --- | --- | --- | --- |
| High | 8 | >50% of turns | Core (pass one) |
| Medium | 12 | 5–50% of turns | 4 to core if in >30% of chains; 8 to long tail |
| Low | 20 |  40 | Two-tier mandatory | Flat registries degrade selection accuracy |
| Core would exceed 15 | Split the agent | 15 is a ceiling, not a target |

Run these five checks against your manifest before your next release. Each one is a yes-or-no question about a number you already have, and together they tell you whether to ship flat, tier now, or split the agent.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Open your MCP tool registry and count every registered schema. If the total sits past roughly 40 tools, stop treating it as a flat list and start splitting it. | The two-tier model is the only architecture that holds selection accuracy above 90% once tool count passes that threshold; below it, a flat registry can still survive. |
| 2 | Promote the 12–15 schemas your agent actually reaches for on most turns into a core tier that is always loaded. | The core tier is the always-loaded set, and its ceiling is 15 schemas — never exceed it, because full schemas consume context window tokens on every call. |
| 3 | Move every remaining schema into a long-tail tier and serve those only through dynamic, contextually-relevant loading. | Dynamic tool loading keeps irrelevant schemas out of the prompt, which is what preserves the accuracy advantage the core tier buys you. |
| 4 | Re-audit the core tier against the 15-schema ceiling after every tool addition, and demote anything that no longer earns its place. | An oversized flat registry degrades selection accuracy precisely because the always-loaded set grows; the ceiling is the guardrail, not a suggestion. |
| 5 | Measure tool-selection accuracy on your own registry before and after the split, and treat the 90% line as the pass/fail boundary. | Accuracy stays above 90% only with a two-tier registry once tool count passes roughly 40 — so the split is justified by your numbers, not by preference. |
| 6 | Adopt the reader rule as standing policy: split every MCP tool registry into a core tier of 12–15 always-loaded schemas plus a long-tail tier served only via dynamic, contextually-relevant loading. | It is the canonical decision rule for this problem, and applying it uniformly prevents the next registry from drifting back into a flat, oversized list. |

## Frequently Asked Questions

**How many schemas should the always-loaded core tier contain?**

Keep the always-loaded core tier to 12–15 schemas; never exceed 15.

**At what tool count does a flat registry start dropping selection accuracy below 90%?**

A flat registry past roughly 40 tools drops selection accuracy below 90%.

**How is the long-tail tier served to the LLM?**

The long-tail tier is served only via dynamic, contextually-relevant loading, not always-loaded.

**What happens to selection accuracy when an oversized flat registry is used?**

An oversized flat registry degrades selection accuracy because full schemas consume context window tokens.

**What mechanism governs the long tail in a two-tier MCP registry?**

The dynamic tool-loading mechanism governs the long tail.

**What does the retrieval step do on each turn?**

On each turn, a retrieval step scores the cu...

## Quick answers

| What is the reader rule for splitting an MCP tool registry? | Split every MCP tool registry into a core tier of 12–15 always-loaded schemas and a long-tail tier served only via dynamic, contextually-relevant loading. |
| --- | --- |
| What is the maximum number of schemas allowed in the always-loaded core tier? | Keep the always-loaded core tier to 12–15 schemas; never exceed 15. |
| When does tool-selection accuracy stay above 90% only with a two-tier registry? | Tool-selection accuracy stays above 90% only with a two-tier registry once tool count passes roughly 40. |
| Why does an oversized flat registry degrade selection accuracy? | An oversized flat registry degrades selection accuracy because full schemas consume context window tokens. |
| How is the long-tail tier served? | The long-tail tier is served only via dynamic, contextually-relevant loading, not always-loaded. |

### Related reading

- [train your productivity agent: 50-entry decision journal before fine-tuning in 2026](https://withtai.com/blog/train-your-productivity-agent-50-entry-decision-journal-before-fine-tuning-in-2026.php)
- [AI Agent Reliability: How to Choose Retraining vs System Redesign](https://withtai.com/blog/ai-agent-reliability-how-to-choose-retraining-vs-system-redesign.php)
- [Weekly Status Report Workflow: Use AI With a 20% Human-Review Gate](https://withtai.com/blog/weekly-status-report-workflow-use-ai-with-a-20-human-review-gate.php)
- [Artificial Intelligence Benchmarks: 50% Success Is a Boundary, Not Production Safety](https://withtai.com/blog/artificial-intelligence-benchmarks-50-success-is-a-boundary-not-production-safety.php)
- [Sales meeting prep agent: 30 to 8 minutes vs chatbot in 2026](https://withtai.com/blog/sales-meeting-prep-agent-30-to-8-minutes-vs-chatbot-in-2026.php)
- [Board Deck Hallucinations: 3-Agent Wins 4-1 vs Single Prompt on 15 Slides](https://withtai.com/blog/board-deck-hallucinations-3-agent-wins-4-1-vs-single-prompt-on-15-slides.php)

### Latest

- [train your productivity agent: 50-entry decision journal before fine-tuning in...](https://withtai.com/blog/train-your-productivity-agent-50-entry-decision-journal-before-fine-tuning-in-2026.php)
- [AI Agent Reliability: How to Choose Retraining vs System Redesign](https://withtai.com/blog/ai-agent-reliability-how-to-choose-retraining-vs-system-redesign.php)
- [Weekly Status Report Workflow: Use AI With a 20% Human-Review Gate](https://withtai.com/blog/weekly-status-report-workflow-use-ai-with-a-20-human-review-gate.php)

Canonical: https://withtai.com/blog/two-tier-mcp-registry-cap-always-loaded-schemas-at-15.php
Markdown: https://withtai.com/blog/two-tier-mcp-registry-cap-always-loaded-schemas-at-15.php/index.md