[MCPServer] Optional ResourcesAsTools support ala FastMCP #3559

Activity

1. wanadzhar913

   changed the title [-][FastMCP] Support for ResourcesAsTools[/-] [+][MCPServer] Optional ResourcesAsTools support ala FastMCP[/+] on Sep 22, 2026
2. claude

   added

   enhancementRequest for a new feature that's not currently supportedRequest for a new feature that's not currently supported

   on Oct 8, 2026
3. ApparentlyTejas commented on Nov 7, 2026

   

   ApparentlyTejas

   on Nov 7, 2026

   More actions

   We have a resource template that's basically this exact shape : evidence://{evidence_id} in an MCP server I maintain, resolving a stored audit-ledger entry by id. Right now it's only usable from clients that speak the resource protocol (Claude Desktop/Code over stdio); a tool-only client like Cursor has no way to call it without list_resources/read_resource support, so this proposal would be the difference between that resource being reachable there or not.

   One thing worth scoping explicitly: resources don't currently have an equivalent of ToolAnnotations (readOnlyHint, destructiveHint, etc.) the way tools do. If ResourcesAsTools auto-generates a tool per resource, should it default those hints (most resources are inherently read-only, so readOnlyHint=True seems like a safe default), or leave them unset until the resource API grows its own annotations? Happy to test against a real server with resource templates if that'd help once there's a draft.
4. ApparentlyTejas commented on Nov 7, 2026

   

   ApparentlyTejas

   on Nov 7, 2026

   More actions

   Been ~6 weeks quiet here, so: are you still planning to scope/open the PR? If so, no need to read further, happy to just watch and test against it once there's a draft, as I mentioned above. If not, I prototyped it to check feasibility and it's small enough that I'd be glad to pick up Phase 1.

   The core idea works cleanly with what's already in MCPServer today, no new infrastructure needed, just wiring. For each resource/template: build a wrapper function with the same signature as the template's underlying function (inspect.signature(template.fn)), register it via mcp.add_tool(...), and let the existing func_metadata machinery derive the input schema automatically, it's the exact same code path @mcp.tool() already uses, so there's no hand-rolled JSON Schema generation to get wrong. On call, resolve the URI from the kwargs and go through the real ResourceTemplate.matches() / create_resource(), not a parallel reimplementation of resource logic.

   ~25 lines, tested against mcp==2.3.0:

   def add_resources_as_tools(mcp: MCPServer) -> None:
       rm = mcp._resource_manager
   
       def make_resource_tool(resource):
           async def _tool():
               return await resource.read()
           return _tool
   
       for resource in rm.list_resources():
           fn = make_resource_tool(resource)
           fn.__name__ = resource.name
           mcp.add_tool(fn, name=resource.name, description=resource.description or "")
   
       def make_template_tool(template):
           async def _tool(**kwargs):
               # template.parsed_template.expand(), not str.format - handles
               # percent-encoding and RFC 6570 operators correctly.
               uri = template.parsed_template.expand({k: str(v) for k, v in kwargs.items()})
               params = template.matches(uri)
               resource = await template.create_resource(uri, params, context=None)
               return await resource.read()
           return _tool
   
       for template in rm.list_templates():
           fn = make_template_tool(template)
           fn.__name__ = template.name
           fn.__signature__ = inspect.signature(template.fn)
           mcp.add_tool(fn, name=template.name, description=template.description or "")

   Against your example from the issue, this produces exactly the tool shape you described: dataset(dataset: str, year: int) with a schema generated from the real function signature, and calling it round-trips through the actual resource template machinery and returns the real content. Also checked it against a value needing percent-encoding (search(query="hello world") → search://hello%20world) to make sure UriTemplate.expand() (not plain str.format) handles that correctly — it does.

   One open question this surfaced that's worth scoping explicitly: context propagation. I pass context=None into create_resource, which is safe today because inject_context only uses it when the resource function itself declares a context parameter, but a resource that does want Context (for logging, elicitation, etc.) needs the generated tool to also declare a context param and forward it, the same way @mcp.tool()-decorated functions do via find_context_parameter. Should the bridging layer detect that automatically (check template.context_kwarg, add a matching ctx: Context param to the generated tool, forward it through), or is that out of scope for a first pass?

   Happy to turn this into a proper PR (with tests, and the context-propagation question above needs an answer first) if that's useful and you're not already deep into one.