> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmcpulse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dynamic registration

> Loading only the tools a request needs turns a routing problem into a retrieval problem — and breaks two metrics silently.

Past about thirty tools, servers increasingly stop shipping the whole list. A lightweight classifier reads the opening message and registers only the tools plausibly relevant to that intent.

As one author put it: **you have quietly turned a routing problem into a retrieval problem.**

That is often the right trade. It also breaks two things MCPulse reports, and the new failure it introduces is silent by construction — the right tool was never a candidate, nothing was called, and nothing distinguishes that from nobody having asked.

## 1. Schema cost stops being one number

[Schema size](/metrics/schema-size) assumes the whole tool list ships on every connection. Under dynamic registration it does not: the payload is whatever the classifier selected, and it differs per session.

MCPulse reports **actual per-session schema bytes** rather than a single startup figure, and flags when the two differ materially — so you know which number you are looking at. A server registering 12 of 120 tools is paying a tenth of the bill the startup figure would suggest, and being told the larger number would be wrong in your favour, which is the worse direction.

## 2. Dead tools becomes ambiguous

"Never called" now means one of two things with completely different fixes:

| What happened                      | What it is                | The fix                                               |
| ---------------------------------- | ------------------------- | ----------------------------------------------------- |
| Never **loaded** by the classifier | A classifier problem      | Retrieval, not wording                                |
| Loaded, never **called**           | A discoverability problem | The [dead-tool taxonomy](/insights/dead-tool) applies |

MCPulse distinguishes them by recording which tools were present in each session's list, not just which were called. Without that, a rewrite gets recommended for a tool the model never saw — advice that cannot possibly work.

<Note>
  This needs no configuration. The startup payload already carries the tool list per session; under dynamic registration it simply carries a different list each time, and that difference is the signal.
</Note>

## 3. Retrieval failure rate

The number that says whether dynamic registration is net positive or just relocating the problem: **how often the classifier excludes a tool that would have been the right answer.**

You cannot currently see this at all. The failure is silent — no wrong call is made, because no call is made.

Measuring it needs ground truth: a labelled set of intent-to-tool pairs, replayed against the classifier. That is the same artefact the [contrastive-prompt harness](https://github.com/getmcpulse/mcp-schema-study) produces, and it is the reason that harness is worth building before you need it.

## Collisions get worse here, not better

The intuition runs the other way, so it is worth stating plainly.

If your classifier reads tool **descriptions** to decide what to load, then two tools a model cannot tell apart are two tools a *classifier* cannot tell apart. The ambiguity does not go away — it moves one layer earlier, to a place where it produces **no wrong call to point at**.

A collision at selection time shows up as a wrong tool in your call log. The same collision at retrieval time shows up as nothing at all.

So the [schema checker](https://getmcpulse.com/check) matters more under dynamic registration, not less. It reads the descriptions your classifier is reading.

## Related

* [Schema size](/metrics/schema-size)
* [Dead tools](/guides/find-dead-tools)
* [Sessions](/metrics/sessions) — why the session boundary is what makes any of this measurable