mcp-content-ops

エージェントがCMSコンテンツを操作できるようにするMCPサーバーです。ツール自体は退屈な部分です — 検索、読み取り、下書き作成、フィールド設定、公開。考える必要があったのは、それらのいずれかを実行する前に起こることです。

私たちが調べたほとんどのコンテンツMCPサーバーは、モデルにAPIクライアントと、統合アカウントがたまたま持っている権限（CMSでは通常すべて）を渡します。デモは機能します。その後、誰かがエージェントに「商品ページを整理して」と頼むと、エージェントは40件の下書きを公開します。なぜなら、システム内のどこにもそれができないとは書かれていないからです。

スコープ設定

4つのゲートがあり、順番に適用されます。それらのいずれもツールスキーマには存在しません。

1. 引数検証 — 公開されたスキーマに照らして行われます。不明なプロパティは破棄されるのではなく拒否されます — 引数をでっち上げたモデルはツールを誤解しており、それを静かに破棄するとその誤解が隠れてしまいます。

2. デフォルトで拒否。 設定で有効にしない限り、書き込みはオフです。Policyのどこにも許可的なデフォルトはありません。

3. 型とフィールドの許可リスト。 型が読み取り可能であっても書き込み可能とは限らず、書き込み可能な型であってもそのすべてのフィールドが書き込み可能とは限りません。

4. すべての呼び出しの構造化監査 — 許可されたものも拒否されたものも、理由付きで記録されます。

呼び出しが判定される型は、保存されたアイテムから取得され、引数からは決して取得されません。呼び出し元が自分が編集しているものの種類を主張できるようにすることは、呼び出し元がどのポリシーが適用されるかを選べるようにすることです。

拒否された呼び出しは、isErrorが設定された通常のツール結果として返され、JSON-RPCエラーではありません。モデルは拒否された理由を確認し、適応する必要があります。プロトコルエラーはクライアントが壊れていることを意味し、それは別の話です。

Related MCP server: ToolBridge

実行方法

pip install -e ".[dev]"
python -m content_ops.server policy.example.json
pytest -q

背後にあるCMSはcms.pyのインメモリスタブです — 4つのメソッドがあり、コンテンツAPIに置き換えてください。

これが行わないこと

削除ツールは意図的にありません。リソースやプロンプトはなく、ツールのみです。認証はありません。これはstdioサーバーであり、信頼境界はそれを起動したプロセスです。スキーマバリデーターは、独自のツールスキーマが使用するサブセットをカバーしており、JSON Schema全体ではありません。

なぜSDKを使わないのか

MCP Python SDKは問題なく、より大きなサーバーではそれが正しい選択です。これはstdio上で3つのメソッドを実装しており、ワイヤーフォーマットは十分に小さいため、SDKが現在動いているペースで動く依存関係の方が大きなリスクでした。