Stub unsupported MCP methods using WordPress initialize capabilities

[mathetos]

When VS Code connects to WordPress through this proxy and mcp-adapter, the connection works and tools show up, but stderr fills with errors like Method not found: resources/templates/list and completion/complete. That came up in WordPress/mcp-adapter#211.

The proxy forwards every MCP method to WordPress, even when WordPress never advertised that capability on initialize. mcp-adapter only handles tools, basic resources, and prompts today, so the -32601 responses are correct on the WordPress side — the problem is that we forward the call and log it as an error.

I'd suggest fixing that by storing initResult.capabilities on SessionContext after a successful initialize, then short-circuiting in createRequestHandler (after waitForInit, before wpRequest) when WordPress didn't advertise support. Return a valid empty stub locally instead of hitting the API — for example { resourceTemplates: [] } for resources/templates/list, and an empty completion result for completion/complete. The same idea applies to subscribe/unsubscribe and logging/setLevel when those caps aren't present. Stubbed calls should log at debug, not error.

Advertised methods like tools/list should keep forwarding as they do now, and servers that do advertise completions or templates should still get the real forward path. Unit tests with nock (similar to init-ready-gate.test.ts) would be great.

One caution from the AGENTS.md: don't casually change the proxy's hardcoded Server constructor capabilities — that caused a race regression in 0.2.20.

[wppoland]

Coming from the adapter side of this: gating on initialize capabilities is the right call, and the detail worth pinning down is what the proxy does when the host asks anyway. We ship a read-only MCP server for WooCommerce and settled on answering resources/templates/list with an empty resourceTemplates array rather than letting the -32601 through, because clients differ in how they treat method-not-found: VS Code logs it as an error, some n8n and Cursor builds retry the probe on every reconnect, which turns one warning into a loop. An empty result is spec-legal, ends the probe, and costs nothing.

The one case where a stub is worse than an error is completion/complete. Returning an empty completion list makes a client believe argument completion exists and is simply empty, so it stops offering its own fallback. Better to leave that one unstubbed and let capability gating do the work. Reference implementation if useful: https://github.com/wppoland/woocommerce-mcp (I work at wppoland.com).