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.
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/listandcompletion/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-32601responses 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.capabilitiesonSessionContextafter a successful initialize, then short-circuiting increateRequestHandler(afterwaitForInit, beforewpRequest) when WordPress didn't advertise support. Return a valid empty stub locally instead of hitting the API — for example{ resourceTemplates: [] }forresources/templates/list, and an empty completion result forcompletion/complete. The same idea applies to subscribe/unsubscribe andlogging/setLevelwhen those caps aren't present. Stubbed calls should log atdebug, noterror.Advertised methods like
tools/listshould 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 toinit-ready-gate.test.ts) would be great.One caution from the AGENTS.md: don't casually change the proxy's hardcoded
Serverconstructor capabilities — that caused a race regression in 0.2.20.