数日前、MCPツールのスキーマのドリフトで遭遇した問題について投稿しました。
要約すると：
MCPサーバーがパラメータを location から city に変更しました。
私のエージェントは location を送り続けていました。
ランタイムまで何も警告してくれませんでした。
その最初のMCP Sentinelは、ただ基本的なアイデアだっただけです：
sentinel init
sentinel snapshot
sentinel check
sentinel diff
それ以来、MCP Sentinel v1.0.0 を出荷しました。
GitHub:
https://github.com/Wannavf/mcp-sentinel
npm:
npm install -g @wannavf/mcp-sentinel
枠組みが少し変わった
元々の問題は、ツールが黙って壊れたので面倒でした。
でもフィードバックの後で、より大事なのはこれだと思うようになりました：
MCPツールのスキーマは契約です。
ツールがパラメータ、必須フィールド、enum値、戻り値の形（return shape）、説明文を変更した場合、それは単なる小さな実装詳細ではありません。
それによって、エージェントが要求できるものが変わります。
さらに、そのツールをエージェントが使うタイミングも変わり得ます。
これは、次のようなMCPサーバーで特に重要です：
databases
filesystems
cloud infrastructure
admin tools
internal APIs
壊れた天気ツールは厄介です。
しかし、黙って変更されたデータベースやインフラ用のツールは、はるかに深刻になり得ます。
v1.0で追加されたもの
最初のバージョンは基本的に：
snapshot
check
diff
v1.0では、より充実したワークフローになりました。
sentinel init
sentinel discover --write
sentinel doctor
sentinel snapshot
sentinel check
sentinel diff
ディスカバリー（Discovery）
Sentinelに、一般的な設定場所からMCPサーバーを見つけるよう依頼できるようになりました：
sentinel discover
sentinel discover --write
MCPの形に合う設定を探し、サーバーをsentinel.config.jsonに取り込むのを手助けできます。
これにより、オンボーディングがより手作業少なくなります。
Doctor（診断）
セットアップ確認が追加されました：
sentinel doctor
Sentinelがあなたの設定を認識できるか、サーバーが正しく設定されているか、ロックファイルが存在するかをチェックします。
何かが動かない理由を推測するのではなく、すぐに健全性（サニティ）チェックが得られます。
ダッシュボード（Dashboard）
端末上のダッシュボードもあります：
sentinel dashboard
または：
sentinel db
設定済みサーバー、スナップショット、チェック、アクティビティ、およびドリフトをローカルで調べられます。
メイン機能ではありませんが、開発中にMCPサーバーをテストする際に役立ちます。
CI
主なユースケースは依然としてCIです。
sentinel check
サーバーがツールの契約を変更した場合、エージェントがランタイムでその破損を発見する前にCIで失敗させられます。
GitHub Actionも用意しています：
name: MCP Schema Check
on: [pull_request]
jobs:
drift:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: Wannavf/mcp-sentinel@main
with:
fail-on: MAJOR
レポート（Reports）
Sentinelは複数の形式で差分（diff）を出力できます：
sentinel diff --format json
sentinel diff --format markdown
sentinel diff --format sarif
SARIFはGitHub Code Scanningにアップロードできます。
トランスポート（Transports）
v1.0は以下をサポートします：
stdio
Streamable HTTP
SSE
stdioの例の設定：
{
"compatibility": "BACKWARD",
"failOn": "MAJOR",
"servers": {
"filesystem": {
"transport": "stdio",
"command": "npx",
"args": [ "-y", "@modelcontextprotocol/server-filesystem", "."]
}
}
}
HTTPの例の設定：
{
"servers": {
"remote": {
"transport": "http",
"url": "http://localhost:3000/mcp"
}
}
}
何を検知するか
Sentinel は変更を MAJOR、MINOR、または PATCH として分類します。
MAJOR の変更例:
ツールが削除された
必須パラメータが削除された
パラメータの型が変更された
省略可能パラメータが必須になった
制約が強化された
列挙値が削除された
出力フィールドが削除された
より安全な変更例:
省略可能パラメータが追加された
ツールが追加された
列挙値が追加された
説明が更新された
すべての変更を止めることが目的ではありません。
ツール契約の変更を明示的にすることが目的です。
なぜ重要だと思うのか
ロックファイルがない場合:
MCP サーバーの変更
エージェントが後で壊れる
実行時にデバッグする
ロックファイルがある場合:
MCP サーバーの変更
CI がドリフトを検知する
契約（コントラクト）の変更内容を確認する
それを受け入れるかどうかを判断する
これは MCP ツール群に欠けているピースのように感じます。
パッケージマネージャーにはロックファイルがあります。
API には契約があります。
MCP ツールのスキーマにも、レビューのポイントがあるべきです。
試してみる
npm install -g @wannavf/mcp-sentinel
または:
npx -y @wannavf/mcp-sentinel --help
GitHub:
https://github.com/Wannavf/mcp-sentinel
npm:
https://www.npmjs.com/package/@wannavf/mcp-sentinel
特に、データベース、ファイルシステム、インフラストラクチャ、または社内の管理ツールで MCP を使っている方からのフィードバックをぜひいただきたいです。
