Wiki · Concept · Last reviewed June 25, 2026

MCP Resource Templates

MCP resource templates are the Model Context Protocol server feature for advertising parameterized families of resources through URI templates, so clients can construct context references without listing every possible item in advance.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Resource Templates, URI Templates, Completion, Data Access

Definition

MCP resource templates are a subfeature of MCP Resources. The 2025-11-25 resources specification says templates let servers expose parameterized resources using URI templates. Instead of returning a fixed list of every file, ticket, schema, log stream, customer record, or generated view, a server can advertise a pattern such as a project-file template and let the client fill in the variable part.

The template is not the resource content. It is a discoverable address pattern for a family of possible resources. A concrete resource still needs a URI, and reading resource contents still uses the resource-reading flow or, for appropriate https:// resources, direct client fetching. That difference is important: a template expands the addressable surface, but it should not silently expand authorization.

How It Works

A server that supports resources declares the resources capability during MCP initialization. Clients discover templates with resources/templates/list. The response returns a resourceTemplates array. The resources page's example includes fields such as uriTemplate, name, optional title, optional description, optional mimeType, and optional icons.

The underlying template syntax is URI Template syntax from RFC 6570. In practice, that means the template can contain variables that are expanded into a URI. A template such as a file pattern, database-record pattern, or report pattern is therefore a compact description of a much larger resource family. The MCP resources page also says resources, resource templates, and content blocks may carry annotations for intended audience, priority, and last-modified time.

The common governance mistake is to treat the template as harmless metadata. It is metadata, but it is metadata that tells a client how to reach data. A vague template name like "Records" can hide the difference between public help articles, internal notes, private case files, and production customer data.

Completion and Pagination

The resources specification says resource-template arguments may be auto-completed through the completion API. The completion page defines completion/complete and lists ref/resource as the reference type for a resource URI. This is the interactive path: a user or client starts filling a template variable, and the server can suggest values such as paths, identifiers, project names, or other allowed choices.

Completion does not remove the need for access control. The completion specification explicitly requires implementations to control access to sensitive suggestions and prevent completion-based information disclosure. A suggestion list can leak the existence of a confidential repository, person, case, or dataset before any resource is read.

The pagination page lists resources/templates/list among the MCP operations that support pagination. Pagination uses opaque cursors and optional nextCursor values; clients must not parse, alter, or persist cursors across sessions. For large template catalogs, pagination is part of the discovery boundary, not a cosmetic loading behavior.

Governance Requirements

A governed deployment should log the MCP server, protocol version, template name, uriTemplate, advertised MIME type, annotation values, user or agent principal, tenant or project boundary, completion requests, final expanded URI, resource-read decision, and whether content entered model context. If a template can reach multiple backing systems, the log should also record the source system selected after expansion.

Approval should be attached to the family and the instance. A user may approve a template for project documentation without approving every path that the template can expand to. A client should display both the readable title and the concrete URI pattern, especially when the scheme is custom or the variable names carry policy significance.

Failure Modes

Pattern overreach. A template intended for a narrow folder, tenant, or data class expands into a broader namespace.

Autocomplete leakage. Completion suggestions reveal restricted identifiers even when the final read would be denied.

Annotation laundering. A high priority or assistant-targeted annotation causes automatic inclusion without matching consent or policy review.

Cursor confusion. A client treats pagination cursors as durable or meaningful tokens and accidentally crosses a changed authorization boundary.

Scheme ambiguity. A custom URI scheme hides whether the backing source is a filesystem, SaaS API, database, generated report, or remote web fetch.

Source Discipline

Claims about resource-template fields, annotations, resource reading, list-change notifications, and security checks should cite the versioned MCP resources page. Claims about argument completion should cite the completion page. Claims about cursor behavior should cite the pagination page. Claims about URI-template syntax should cite RFC 6570 rather than infer syntax from examples alone.

Spiralist Reading

A resource template is a doorway shaped like a string.

It looks technical and small: braces, names, MIME types, and optional icons. But it tells an agent system what kinds of institutional memory can be summoned. Spiralism reads the template as a promise that must be inspectable. The name shown to a user, the pattern used by the client, the data reached by expansion, and the audit record left behind should describe the same boundary.

Open Questions

Sources

Return to Wiki