ProxyProvider advertises hardcoded capabilities instead of forwarding backend server capabilities

[garethjevans]

What happened?

Description

create_proxy() / ProxyProvider advertises a hardcoded set of MCP capabilities (tools, resources, prompts) during initialization, regardless of what the backend server actually supports. This causes clients to make requests for unsupported features and receive incorrect responses.

Expected Behavior

The proxy should:

1. Forward the backend server's actual serverCapabilities from its initialize response
2. Only advertise capabilities that the backend server supports
3. Forward backend JSON-RPC error responses (like "Method not found") instead of converting them to successful responses

Actual Behavior

1. Hardcoded capabilities: Proxy always advertises full MCP capabilities:

   "capabilities": {
     "experimental": {},
     "logging": {},
     "prompts": {"listChanged": true},
     "resources": {"subscribe": false, "listChanged": true}, 
     "tools": {"listChanged": true},
     "extensions": {"io.modelcontextprotocol/ui": {}}
   }

2. Backend capabilities ignored: When backend server only supports tools (no prompts/resources), proxy still advertises all capabilities

Example Code

from fastmcp.server.server import create_proxy
from fastmcp.client.transports import StreamableHttpTransport
from fastmcp import Client

# Create proxy to backend server that only supports tools
transport = StreamableHttpTransport(url="http://tools-only-server/mcp")
proxy = create_proxy(transport, name="proxy")

async with Client(proxy) as client:
    # Bug 1: Initialize returns full capabilities even though backend only supports tools
    result = await client.initialize()
    print(result.capabilities)  # Shows prompts/resources support incorrectly
    
    # Bug 2: resources/list returns empty list instead of "Method not found" error
    resources = await client.list_resources()  # Should error, but returns []

Version Information

- FastMCP version: 3.2.4
- Python version: 3.13.12
- MCP protocol version: 2024-11-05
- OS: macOS

[gnanirahulnutakki]

I dug into this locally and I don’t think a clean fix lives entirely in proxy.py.

What I found:

• FastMCP advertises capabilities from LowLevelServer.create_initialization_options() / get_capabilities().
• Those InitializationOptions are created when the server transport/session starts (src/fastmcp/server/mixins/transport.py, src/fastmcp/server/http.py, and the in-memory transport), before the client sends initialize and before a proxy can asynchronously initialize the backend.
• ProxyProvider only discovers unsupported list methods later via client.list_*(), and AggregateProvider intentionally degrades list exceptions into “log and continue”.
• Because of that, simply removing the METHOD_NOT_FOUND catch in ProxyProvider is not enough: resources/list / prompts/list would still collapse into successful empty results at the aggregate server layer, and the initialize response would still advertise the wrong capabilities.
• There is also a composition question for FastMCPProxy: if the proxy has local tools/resources/prompts layered on top of the backend, the right answer is not always “backend capabilities only” but rather “backend capabilities plus proxy-local additions”.

The two clean paths I see are:

1. Add a capability API / preload hook so providers like ProxyProvider can expose backend capabilities before InitializationOptions are frozen for a session.
2. Make initialization capability synthesis per-connection/async so create_proxy() can initialize the backend first and then build merged capabilities from backend support plus any proxy-local additions.

If maintainers want, I can split this into a smaller first step that fixes the later list-method behavior, but I didn’t want to open a PR against #3948 that still leaves the initialize response lying about supported capabilities.

[jlowin]

Thanks for the detailed report. An attempt at this landed in #3956 and was reverted in #3964 once the implementation got out of proportion to the problem.

Stepping back: the report assumes the proxy should mirror its upstream. The object is better understood as a gateway, a server in its own right that happens to be backed by upstreams and can also have local components layered on top. Under that framing its capabilities are its own, not a reflection of any particular upstream, and resources/list returning [] when the backend has no resources is the correct response for a capable server with zero resources. No protocol violation, no data loss.

Going to close as working-as-intended. If you hit a concrete scenario where the empty-list behavior actually breaks a client or workflow (rather than just diverging from METHOD_NOT_FOUND on paper), please reopen with the repro and I'll take another look.

[gnanirahulnutakki]

Thanks for the clarification. Under the gateway framing, that behavior makes sense, and I agree this report does not justify a code change on its own. I’m stepping back from this one; if I hit a concrete client/workflow break caused by the empty-list behavior, I’ll come back with a focused repro instead of the protocol-level argument.