#2164·openclaude

Add bounded MCP resource-template discovery

Author: chioarubCreated Aug 23, 2026Updated Aug 23, 2026

Problem

OpenClaude discovers MCP tools, concrete resources, and prompts, but it does not request resources/templates/list. A server that exposes only parameterized resources such as file:///{path} is therefore invisible to the model even though the installed MCP SDK supports the operation.

I confirmed the gap with an in-memory MCP server. The server declared the resources capability, returned no concrete resources, and returned one resource template. OpenClaude sent one resources/list request, no resources/templates/list request, and no resources/read request. A direct call through the installed SDK returned the template.

The current dependency is @modelcontextprotocol/sdk v1.29.0. OpenClaude does not pin the client protocol version, so that SDK currently offers MCP 2025-11-25 first and also supports 2025-06-18. Both production revisions define paginated resource-template listing. The installed v1 package exports the official request and result schemas and the ResourceTemplate type.

Proposed first version

  • Discover templates only for connected servers that declare the resources capability.
  • Validate each response with the installed SDK's ListResourceTemplatesResultSchema.
  • Reuse the existing 100-page and 10,000-item MCP list bounds, exact opaque cursors, empty-string cursor support, and repeated-cursor protection.
  • Add the OpenClaude server name by cloning each SDK template rather than mutating it.
  • Treat JSON-RPC Method Not Found, code -32601, as an empty template list for legacy servers.
  • Keep malformed responses, transport errors, repeated cursors, and bound violations as failures.
  • Cache only complete successful traversals.
  • Invalidate concrete-resource and template caches together when the connection closes, configuration changes, a server is disabled or removed, or notifications/resources/list_changed arrives.
  • Refresh concrete resources and templates as one cache and state transaction. If either required refresh fails, restore the previous cache entries and retain the previous complete AppState.
  • Serialize resource-list notifications per client so an older traversal cannot overwrite a newer refresh.
  • Add a deferred read-only ListMcpResourceTemplatesTool beside the existing concrete resource tools. Keep ListMcpResourcesTool unchanged.
  • Return uriTemplate, name, optional title, description, mimeType, safe annotations, and server.
  • Project away SDK _meta and icons before caching. Retain at most 1,000,000 UTF-8 bytes of safe template metadata per server and stop a complete traversal after 60 seconds.
  • Sanitize untrusted strings, cap descriptive fields at 2,048 characters, keep the URI template exact, and reject model-facing JSON over 100,000 characters. The tool will not persist a raw oversized result.
  • Cover the direct SDK and headless print connection path as well as the interactive connection manager. Same-name SDK removal and replacement will invalidate the shared caches before cleanup.

The model can construct a concrete URI from a discovered template and explicitly call the existing ReadMcpResourceTool. Discovery itself will not expand variables, enumerate values, call completion, or read a resource.

Compatibility and security

This keeps the concrete resource output contract unchanged. A resources-capable server that does not implement template listing continues to work because only code -32601 maps to no templates. Other errors stay visible as server-scoped discovery failures, and one failing server does not remove templates returned by another server.

Server-provided names, descriptions, templates, and annotations are untrusted. The implementation will expose only annotation audience, priority, and lastModified. It will not expose SDK _meta, render icons, log template values or cursors in telemetry, infer that file:// refers to the local filesystem, bypass MCP authorization, or persist cursors.

Test plan

Deterministic fake clients and an in-memory SDK server will cover legacy Method Not Found, template-only and mixed servers, exact multi-page ordering, empty and repeated cursors, malformed cursors and results, page, item, byte, and time limits, source immutability, non-sticky failures, cache hits and invalidation, serialized list-changed refresh, atomic state and cache preservation, lifecycle clearing, direct SDK remove and re-add, cross-server isolation, server filtering, missing-server errors, sanitization, output bounds, and the absence of automatic read, completion, or URI expansion.

Existing concrete resource tests must remain unchanged and pass.

Out of scope

  • completion/complete
  • resource subscriptions and updated notifications
  • parameter forms or automatic template expansion
  • resource prefetch
  • local filesystem interpretation
  • permission-rule, prompt, or authorization changes beyond classifying the new tool with existing read-only helpers
  • an MCP SDK upgrade or new dependency
  • a general MCP resource redesign

Approval request

Would maintainers approve this narrow first version before implementation starts? In particular, please confirm that a separate deferred listing tool and the -32601 compatibility rule fit the project's MCP direction.