MCP（Model Context Protocol）はAIアプリと外部ツール・データソースを統一仕様で接続する標準規格で、MCPサーバーはそのハブとして機能する。JSON-RPC 2.0で通信し、リソース・プロンプト・ツールという要素でAIと外部システムを連携させる。導入により複数ツール横断の業務自動化や開発コスト削減が期待できる一方、実行経路の追跡困難、意図しないツール操作リスク、原因特定の難しさ、処理遅延といった課題が生じやすく、これらに対処するオブザーバビリティの重要性をNew Relicの製品紹介とともに解説している。
MCPゲートウェイManifoldに、OPAサイドカーを用いたツール単位の認可機能を追加。ManifoldはPEP（強制のみ）、OPAはPDP（Rego judgeによる許可判定）として役割を分離し、tools/callは呼び出しごとに判定、tools/listは許可ツールのみに絞り込む。判定不能時は全て拒否するfail-closed設計を採用し、ポリシー作成者向け全ツールカタログAPIやテナント単位のバイパスヘッダーも実装。接続可否を扱う標準仕様EMA（Enterprise-Managed Authorization）とは効くレイヤーが異なり（EMA=サーバー単位・接続時、Manifold+OPA=ツール単位・リクエスト時）、両者は補完関係にあると位置づけている。
OpenAIはMCPサーバーからスキルを配信する仕様案「Skills Over MCP」に早期対応した。公開プラグインの提出フローで「Scan Tools」を選択すると、MCPサーバー上のSKILL.mdと関連ファイルを取得しプラグインへ取り込める。ツールとスキルを一元管理でき、両者のバージョンずれを抑えやすくなる。MCP仕様案SEP-2640の一部を先行採用したもので、更新の反映は都度自動ではなく提出・審査のタイミングで行われる。
自社DBを社内から自然言語で問い合わせられるようにするため、Google製OSS「MCP Toolbox for Databases」でMCPサーバを構築した事例。AIにSQLを直接生成させる方式は再現性・業務ルール反映の面で破綻したため、人間がレビュー済みのSQLをYAMLでツール定義し、AIはツール選択のみ行う方式に変更。認証は自前実装だが本家機能への移行を検討中、読み書きエンドポイントの分離やtoolsetsによるツール管理、運用後は利用ツールが偏る傾向が判明したことなどを紹介している。
Claude CodeなどのMCPクライアントからCloud Run上のMCPサーバへ安全に接続するための認可構成を検討した記事。MCPの認可仕様はOAuth 2.1をベースにProtected Resource Metadata（RFC 9728）やAuthorization Server Metadata（RFC 8414）による動的解決、Client ID Metadata Documents（CIMD）によるクライアント登録を要求する。Cloud Run標準のIAMやIAPはMCPクライアントがID/アクセストークンを扱う前提と噛み合わず利用できないため、Googleを上流IdPとする認可サーバを自前実装する構成と、Auth0のAuth for MCPなどMCP対応の外部IdPを利用する構成の2案を提示し、token passthroughのアンチパターン回避や運用負荷を踏まえ外部IdP製品の採用を推奨している。
Next.jsやReactで非互換な旧バージョンのコードがAIに生成される問題を解決するため、最新ドキュメントをAIコーディングアシスタントに直接渡せるContext7 MCP ServerをCursor・Claude Desktop・Claude Codeの3環境に導入する手順を紹介する記事。