Summary
The MCP stdio + HTTP server advertises the resources capability but does not implement resources/templates/list. Compliant MCP clients (Claude Desktop, Cursor, Zed) probe resources/templates/list after seeing the resources capability in initialize and today get -32601 Method not found instead of an empty resourceTemplates array.
Problem
The current initialize capability block on main is:
{
"capabilities": {
"tools": {},
"resources": { "subscribe": false, "listChanged": false }
}
}
With resources advertised, the spec invites clients to call all three resource discovery methods (resources/list, resources/read, resources/templates/list). Calling the third returns:
{ "error": { "code": -32601, "message": "Method not found", "data": "unsupported MCP method `resources/templates/list`" } }
Clients log this as a spec violation (cosmetic - graceful fallback) but it pollutes their debug surface and signals an incomplete server. The catalog is fully static, so the correct response is an empty resourceTemplates array; the handler is a one-line stub.
Solution (optional)
Add resources/templates/list to handle_request in src/openhuman/mcp_server/protocol.rs returning { "resourceTemplates": [] } from a new resources::list_resource_templates_result() helper. No capability change (still under the existing resources block). No URI scheme change.
Acceptance criteria
Related
Summary
The MCP stdio + HTTP server advertises the
resourcescapability but does not implementresources/templates/list. Compliant MCP clients (Claude Desktop, Cursor, Zed) proberesources/templates/listafter seeing theresourcescapability ininitializeand today get-32601 Method not foundinstead of an emptyresourceTemplatesarray.Problem
The current
initializecapability block onmainis:{ "capabilities": { "tools": {}, "resources": { "subscribe": false, "listChanged": false } } }With
resourcesadvertised, the spec invites clients to call all three resource discovery methods (resources/list,resources/read,resources/templates/list). Calling the third returns:{ "error": { "code": -32601, "message": "Method not found", "data": "unsupported MCP method `resources/templates/list`" } }Clients log this as a spec violation (cosmetic - graceful fallback) but it pollutes their debug surface and signals an incomplete server. The catalog is fully static, so the correct response is an empty
resourceTemplatesarray; the handler is a one-line stub.Solution (optional)
Add
resources/templates/listtohandle_requestinsrc/openhuman/mcp_server/protocol.rsreturning{ "resourceTemplates": [] }from a newresources::list_resource_templates_result()helper. No capability change (still under the existingresourcesblock). No URI scheme change.Acceptance criteria
resources/templates/listreturns{resourceTemplates: []}- wired throughhandle_json_valueend-to-end, not just the helper.-32602 Invalid params.handle_json_valuetests (bare + with cursor).gitbooks/developing/mcp-server.md(+ zh-CN) get a Resource Templates note and the smoke-test snippet exercises the new method;docs/TEST-COVERAGE-MATRIX.mdadds a row under 11.1.Related
resources/templates/listas deliberate out-of-scope follow-up tracking.resourcescapability +resources/list/resources/readon main; this issue extends that surface.