Claude の拡張Claude apps and Claude Code

Anthropic / mcp-builder

スキルではなく MCP サーバーを作るべきなのはいつか

エージェントが知る必要があるときではなく、何かをする必要があるときです。

押さえておく点

  1. ツール設計がすべてです。名前の悪いツールは使われないツールです。
  2. 重複した多数のツールより、範囲の明確な少数が勝ります。
  3. エラーメッセージはインターフェースの一部です。エージェントはそれを読んで次を決めます。
  4. サーバーは能力を与えるものであり、能力には権限の境界が必要です。

01実務で何が変わるか

MCP の難所はプロトコルではなくインターフェース設計です。エージェントは名前と説明からツールを選ぶため、process という名前でオプションオブジェクトを受け取るツールは常に誤用されます。

明示的な指針をもって作ると、見取り図が小さく読みやすく保たれます。エージェントが正しく使うサーバーと、避けるか誤用するサーバーの差はそこにあります。

02期待に届かない点

セキュリティモデルは決めてくれません。エージェントが何を読み、書き、消せるのかは自分たちの決定であり、サーバー側で強制する必要があります。

プロトコルの詳細も動きます。スキルに写し取られた内容が最新だと仮定せず、現行の仕様を確認してください。

導入と最初の実行

  1. anthropics/skills から Apache 2.0 で導入します。
  2. 先にツールの見取り図を決めます。数は少なく、名前は明確に、引数は自明に。
  3. 現実的で最も曖昧な依頼で試します。悪い境界はそこで露見します。

実際によくある質問

スキルと MCP サーバーのどちらですか
手順と規約ならスキル、能力、つまり他の手段では届かないシステムへのアクセスならサーバーです。
よくある設計の誤りは
曖昧な名前で重複した多すぎるツールです。選択が不安定になります。
エラーメッセージは重要ですか
重要です。エージェントはそれを読んで次の手を選ぶため、インターフェースの一部として扱ってください。

出典

  1. GitHub の anthropics/skillsrepository
  2. anthropics/skills、mcp-builder スキルのディレクトリdocumentation

このページの機械可読版