翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ツール定義
<a name="mcp-tool-strategy-definitions"></a>

LLM は、直接処理できないリクエストを受信すると、リクエストの完了に役立つ利用可能なツールを確認します。LLM は、提供されたツールの名前と説明、およびプロンプトで提供された手順のセマンティック理解に基づいてツールを選択します。次に、定義された入力スキーマに基づいて入力を作成し、出力スキーマに基づいて出力を期待します。したがって、LLM がツールを効果的に選択できるようにするには、わかりやすいツール定義と検証済みの入出力スキーマを作成することが重要です。通常、このドキュメントの作成にはツール仕様アプローチとドキュメント作成アプローチの 2 つのアプローチがあります。

## ツール仕様のアプローチ
<a name="mcp-tool-strategy-definitions-spec-approach"></a>

推奨されるアプローチは、[ツールを定義するときに MCP ツールの仕様](https://modelcontextprotocol.io/specification/2025-06-18/server/tools#tool)に直接従うことです。次の例は、[Strands Agent](https://strandsagents.com/docs/user-guide/quickstart/overview/) ツールデコレータを使用して示されています。

```
@tool(
  name = "search_website",
  description = "This tool searches the provided website for semantic matches to the query provided",
  inputSchema = {
    "json": {
      "type": "object",
      "properties": {
        "url": {
          "type": "string",
          "description": "The url of the website to load and search."
        },
        "query": {
          "type": "string",
          "description": "The content you want to try and match in the website."
      }
    },
    "required": ["url", "query"]
  },
  outputSchema = {
    "json": {
      "type": "object",
      "properties": {
      "results": {
          "type": "array",
          "items": {
            "type": "string" 
          }
        }
      }
    }
  }
)
def search_website:
  …
```

、、`name`、 `description`などの標準フィールドを使用すると`inputSchema`、LLM と人間の両方が理解できる一貫したドキュメントがすべてのツールに`outputSchema`用意されます。すべてのツールは、少なくともこれらのフィールドを定義し、オプションでタイトルと注釈を提供する必要があります。これは、ツールの動作に関するオプションのヒントです。可能であれば、LLM が正しいオプションを簡単に選択できるように、パラメータ値に列挙型を使用します。列挙型は、ステータスや優先度の値などの有限セットに最適ですが、自由形式のテキスト、動的値、任意の数値、リソース識別子には適していません。このような場合は、代わりに明確な説明と例を提供します。また、可能な場合はデフォルト値を含めます。これにより、LLM は正しいオプションを推測する必要はありません。ツール定義は、各呼び出しの LLM プロンプトに含まれ、システム命令と会話履歴とともにコンテキストウィンドウスペースを消費することに注意してください。

## Docstring アプローチ
<a name="mcp-tool-strategy-definitions-docstring-approach"></a>

Python でツールを記述する場合のもう 1 つのアプローチは、docstrings を使用してツールの説明、使用状況、出力を提供することです。このアプローチの例を次に示します。

```
def search_website(url: str, query: str) -> list:
    
    """
    This tool loads the specified website and then attempts to find content that matches the provided query through semantic search. It provides back a list of strings that are the sentences that match the query. 
    Args:
      url: the website url to load
      query: the content you want to semantically match in the website
    """
```

Docstrings はスキーマや標準化された形式を適用しません。このアプローチを使用すると、ツール開発者が各ツールをどのようにドキュメント化するかに基づいて、一貫性のない結果が得られる可能性があります。このアプローチに従うには、組織全体の標準を定義して適用することが不可欠です。

## MCP ツール定義のベストプラクティス
<a name="mcp-tool-strategy-definitions-best-practices"></a>
+ **MCP ツールの仕様に従う** – すべてのツールに `name`、`description`、`inputSchema`、および `outputSchema`フィールドを指定します。Python 実装では、[Pydantic モデル](https://docs.pydantic.dev/latest/concepts/models/)を使用して、フィールドの説明、自動型検証、列挙型による制約値を通じてインラインドキュメントを提供します。これにより、スキーマが自己文書化され、有効なパラメータオプションに対する LLM の理解が向上します。
+ **プロンプトとして記述する** – ツールの説明は、LLM の意思決定をガイドする手順です。ツールの目的の必須コンポーネント (ツールの動作）、ツールを使用するタイミング (ユーザーのインテントパターンまたはシナリオ）、出力のコンテキスト (出力が使用される内容）、パラメータ、エラー条件を含めます。
+ **具体的な例を提供する** – 実際の値を含むワークフロー例を含めることは、正しいツールの使用について LLMsガイドする最も効果的な方法です。
+ **依存関係を明示的に文書化**する – 前提条件、番号付きシーケンス、状態の変更、フォローアップアクションを含めます。