Static MCP resources are easy to understand: a server advertises a URI, the client reads it, and the agent gets useful context. That works well for known files, fixed database schemas, and stable documents. It breaks down when the useful resource depends on a parameter.

Resource templates solve that problem. They let an MCP server expose a pattern, not just a fixed URI. Instead of listing every possible file, customer record, issue, table, or log stream up front, the server can publish a URI template such as file:///{path} or postgres://tables/{tableName}/schema. The client fills in the variables when it needs a specific resource.

The Core Idea

An MCP resource template is a parameterized resource definition. It says: “this server can provide resources that match this URI shape.”

A normal resource has a concrete uri:

{
  "uri": "file:///project/README.md",
  "name": "README.md",
  "mimeType": "text/markdown"
}

A resource template has a uriTemplate:

{
  "uriTemplate": "file:///{path}",
  "name": "Project Files",
  "description": "Access files in the project directory",
  "mimeType": "application/octet-stream"
}

That one template can represent many resources. The server does not need to enumerate the whole project tree. The client can request file:///src/index.ts, file:///package.json, or another path that fits the template.

This matters because many agent workflows need targeted context. An agent usually does not need every resource a server can access. It needs the one matching the current task.

How It Works

Resource templates use the resources/templates/list method. A client asks the server which templates are available, and the server returns a list of template definitions.

Each template can include:

  • uriTemplate: the parameterized URI pattern
  • name: a short identifier
  • title: a display-friendly name for humans
  • description: what the template is for
  • mimeType: the expected content type
  • optional icons and annotations for client UIs

Once the client has a template, it can construct a concrete URI and call resources/read with that URI. The read operation is still the same. The difference is discovery. Static resources are discovered one by one through resources/list; resource templates are discovered as patterns through resources/templates/list.

Arguments may also be paired with MCP’s completion API. That lets clients offer autocomplete for template variables. A database server could help complete table names. A Git server could complete branch names. A documentation server could complete package names or version strings.

Why It Matters for AI Agents

Resource templates make context access more scalable. Without templates, a server with 50,000 possible resources has two bad choices: list everything or hide most of it behind tools. Listing everything is slow and noisy. Hiding data behind tools can blur the line between “read context” and “take action.”

Templates keep the read path clean. They tell the agent, client, and user that this is still context, not an operation with side effects. The server is exposing data that can be read by URI. The URI just contains variables.

That distinction helps with safety. Reading github://repos/acme/api/issues/123 is different from calling a tool named close_issue. Reading postgres://tables/users/schema is different from running a migration. A good client can present templates as selectable context sources while reserving stricter approval flows for tools that write, delete, send, or deploy.

Templates also help agents ask better questions. If a server exposes docs://packages/{packageName}/{version}, an agent can infer that package and version are meaningful dimensions. The template becomes part of the server’s interface, not buried in prose.

Resource Templates in Practice

A code assistant connected to a project filesystem is the simplest example. The server could list a few high-priority static resources, such as README.md and package.json, while also exposing a template for arbitrary project files:

{
  "uriTemplate": "file:///{path}",
  "name": "project-file",
  "title": "Project file",
  "description": "Read a file from the current project workspace",
  "mimeType": "application/octet-stream"
}

When the user asks, “Why is the login route failing?”, the agent can inspect stack traces, infer that src/routes/login.ts matters, and read file:///src/routes/login.ts through the template. The server did not need to advertise every file as a separate resource.

A database server might expose a schema template:

{
  "uriTemplate": "postgres://schemas/{schemaName}/tables/{tableName}",
  "name": "table-schema",
  "description": "Read table metadata for a database table",
  "mimeType": "application/json"
}

That gives an agent a safe way to inspect structure before writing SQL. It can read table metadata, understand columns and indexes, and only then decide whether it needs a separate query tool.

When to Use Templates Instead of Static Resources

Use static resources when the list is small, stable, and useful as a menu. A README, an API overview, or a canonical configuration file belongs in resources/list.

Use resource templates when the useful resource is selected by parameter. Files by path, issues by ID, records by key, docs by version, and logs by service name are all good fits.

Avoid templates when the operation is not really a read. If filling in the URI triggers a job, changes state, sends data to another system, or performs a costly action, it should probably be a tool with clear annotations instead. Resource templates are for addressable context.

FAQ

Q: Are MCP resource templates the same as tools? A: No. Tools execute operations. Resource templates define patterns for reading resources. A template should return context through resources/read, not perform a write or external action.

Q: Do clients have to show resource templates in the UI? A: No. MCP does not require a specific interface. A client can show templates in a picker, use them for agent-driven context selection, pair them with autocomplete, or hide them behind its own workflow.

Q: Can a server expose both static resources and templates? A: Yes. That is often the best design. Static resources cover the obvious context. Templates cover the long tail of parameterized resources.

Q: What makes a good URI template? A: Use stable names, clear variables, and schemes that match the resource domain. The template should make it obvious what kind of context will be returned and which parameters the client needs to provide.