AIのコーディングアシスタントを検証する WordPress 代わりに、それを推測する。

wp-devdocs-mcp は、WordPress、WooCommerce、Gutenberg、または使用するプラグインから、すべてのアクション、フィルタ、ブロック登録、および JS API 呼び出しをインデックス化するローカル MCP サーバーです。 Claude CodeのようなAIツールは、トレーニングデータに依存するのではなく、検証されたデータベースとして検索し、検証します。

Claudeコード、Cursor、Windsurf、およびMCP互換クライアントで動作します。

なぜこの例

AI コーディングアシスタントは、WordPress プラグインの作成方法を変更しています。 Claudeコード、カーソル、Windsurfなどのツールは、プラグイン全体を数分でスキャフォールドできますが、それらはすべて同じブラインドスポットを共有します。hookの名前は、実際のソースコードからではなく、トレーニングデータから来ています。

ほとんどの場合、この作品はうまくいきます。 モデル のような クラウド ソンネット 釘 普通 ホック ほぼ毎回. しかし、「ほとんどの場合」は、製造コードを出荷する際に十分ではありません。すべてのモデルがクロードソンネットではありません。 今日のコード生成を行うLMSの風景を渡って:

• 存在しないモデルの発明のホック - [woocommerce_email_after_order_detailsは右ではなく、実際の音を鳴らす -**"{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}{{{{{{{{{{{{{{{{{{{{{{{{{{}}}}}}}}{{{{{{{{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}}{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}}}}}}}}}}.

wp-devdocs-mcp

Give your AI coding assistant a verified WordPress hook database instead of letting it guess.

wp-devdocs-mcp is a local MCP server that indexes every action, filter, block registration, and JS API call from WordPress, WooCommerce, Gutenberg, or any plugin you work with. It gives AI tools like Claude Code a verified database to search and validate against instead of relying on training data.

Works with Claude Code, Cursor, Windsurf, and any MCP-compatible client.

Why This Exists

AI coding assistants are changing how we build WordPress plugins. Tools like Claude Code, Cursor, and Windsurf can scaffold entire plugins in minutes — but they all share the same blind spot: hook names come from training data, not from the actual source code.

Most of the time this works fine. Models like Claude Sonnet nail common hooks almost every time. But “most of the time” isn’t good enough when you’re shipping production code, and not every model is Claude Sonnet. Across the landscape of LLMs doing code generation today:

• Some models invent hooks that don’t exist — woocommerce_email_after_order_details sounds right but isn’t real
• Some use deprecated namespaces — wp.editor.InspectorControls instead of wp.blockEditor.InspectorControls
• Most miss newer hooks — suggesting pre_get_posts for WooCommerce order queries when HPOS uses woocommerce_order_list_table_prepare_items_query_args
• Parameters get mixed up — wrong argument count or order in callback signatures
• No model knows your custom plugins — private or proprietary hooks are invisible to every model’s training data

The core issue is simple: we can’t rely 100% on any model to produce correct WordPress hook names from memory alone. Even the best models benefit from verification, and the rest genuinely need it. You only find out about hallucinated hooks when the code doesn’t work — and in an agentic workflow where the AI writes, tests, and iterates autonomously, one bad hook name can send it down a rabbit hole of debugging something that was never going to work.

The Solution

Feed the LLM real data. Instead of hoping the model remembers the right hook name, give it a verified database to query.

wp-devdocs-mcp parses the actual source code of any WordPress plugin and builds a searchable index of every hook with its exact name, type, parameters, file location, and surrounding code context. Your AI assistant queries this index before writing code — so every hook name in the generated code is verified against the real source.

This fits naturally into agentic coding workflows. When Claude Code (or any MCP-compatible assistant) needs to use a WordPress hook, it:

1. Searches the indexed database for relevant hooks