Automattic / Automattic/mcp-wordpress-remote

Stub unsupported MCP methods using WordPress initialize capabilities

Open
#91 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
180
Forks
35
PR merge metrics
No merged PRs in 30d

Description

When VS Code connects to WordPress through this proxy and [mcp-adapter](https://github.com/WordPress/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](https://github.com/WordPress/mcp-adapter/issues/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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Read AGENTS.md, then trace SessionContext and createRequestHandler around waitForInit and wpRequest to see how initialize capabilities and MCP methods are handled. Use init-ready-gate.test.ts as the model for nock-based unit tests; done means unsupported calls return the specified empty results and debug logs without forwarding, while advertised methods retain the existing forward path.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.