Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it persists settings, merges services by default, and requires user-provided IDs. However, it does not describe side effects like overwriting vs merging existing settings beyond services, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: the first states the purpose, the second specifies what to pass, and the third gives behavioral and usage notes. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key context (when to call, what to pass, what it does) but is missing details about return values, error conditions, and idempotency. The export_dir parameter is unexplained. Given no output schema, more completeness would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (80%) with descriptions for most parameters. The description adds context for root_page_id/url and services, and notes the default merging behavior for merge_services. However, export_dir has no schema description and is not mentioned in the description, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool persists per-user workspace settings and specifies it is NOT in the repo .env, distinguishing its scope. It directly links to sibling tool plan_status, providing context for when this tool is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call after plan_status when root_page_id is missing and includes strong guidance to ask the user for their root page and never invent IDs, providing clear when-to-use and when-not-to-use rules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full responsibility. It discloses that the tool creates the page if missing, and mentions required access tokens. This covers the core behavior adequately, though it could detail idempotency or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The key information is front-loaded, and each sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 params, no output schema, no annotations), the description is mostly complete, covering purpose, behavior, and prerequisites. It could benefit from mentioning the return value or idempotency, but overall it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (dry_run lacks a description). The description does not add any parameter-specific meaning beyond the schema, leaving the dry_run parameter unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Ensure a service page exists under the configured Plans root. Creates if missing.' It uses a specific verb ('ensure') and resource ('service page'), and the name 'plan_ensure_service' aligns with this purpose, distinguishing it from siblings like 'plan_get' or 'plan_upsert'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit prerequisites: 'Requires plan_configure + NOTION_TOKEN.' While it does not explicitly state when to use this tool vs. alternatives or when not to use it, the clear purpose implies its appropriate context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description discloses read operation, output features, and authentication requirement. Lacks details on rate limits or error behavior but sufficient for basic usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, highly concise, purpose stated upfront, no filler. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite clear output description, the tool has 6 parameters with no schema descriptions and no output schema. The description fails to explain parameter roles or provide enough context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and description provides no explanation for any of the 6 parameters (title, page_id, service, sections, max_lines, with_lines). Agent cannot infer how to populate inputs from description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Fetch' and specific resource 'plan', with detailed output format (addressable markdown, line numbers, TOC, etag). Distinguishes from siblings by mentioning relation to plan_update_range.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states to call before plan_update_range and lists required prerequisites (plan_configure + NOTION_TOKEN). No explicit when-not-to-use or alternative sibling tools mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses upsert behavior and internal chunking, but omits critical details: what happens on failure (file not found, missing service), whether mode affects behavior differently, or if the tool is safe to re-run. Limited transparency for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the purpose and then state prerequisites and internal behavior. No unnecessary words; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and no annotations, the description fails to cover error states, return values, or detailed parameter semantics. Missing guidance on how mode or dry_run affect operation, leaving significant gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60% (3 of 5 parameters described). Description adds context about upsert and chunking but doesn't clarify the purpose of mode or dry_run parameters. Does not compensate adequately for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool migrates a local markdown file into Notion plan bank, specifying verb 'Migrate' and resources (local file, Notion plan bank). It distinguishes from siblings like plan_upsert by emphasizing the file-based input and internal chunking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions prerequisite (plan_configure + NOTION_TOKEN) and notes that chunking is handled internally, providing some guidance. However, lacks explicit when-to-use vs alternatives like plan_upsert or plan_sync, and no when-not-to scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that a browser opens and login auto-runs, but lacks details on blocking behavior (wait parameter), timeout, potential side effects, or what happens if already logged in. The description is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three short sentences, each adding value. It front-loads the purpose, includes key behavioral hints, and avoids any waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple OAuth login tool with no output schema and three parameters, the description covers the main behavior and automation feature. It misses parameter details but is otherwise complete enough for an agent to understand the core functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only 'wait' has a description). The description does not explain any parameter beyond the schema, such as timeout_ms or open_browser, so it adds minimal value. Given low coverage, it should compensate but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool opens a browser for Notion login, specifies the domain (mcp.notion.com), and distinguishes itself by noting auto-run behavior and absence of client credentials. This differentiates it from siblings like plan_oauth_logout and plan_oauth_wait.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool auto-runs on first use if not logged in, implying when it's triggered. It also mentions no CLIENT_ID/SECRET needed, setting expectations. However, it does not explicitly state when not to use it or provide alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses the critical behavioral trait that it does not revoke at Notion end, which is essential for agent decision-making.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with zero waste. Front-loaded with action and key limitation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters or output schema, the description fully covers the behavior and limitation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, baseline 4. No need for parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it clears saved OAuth credentials locally. Distinguishes from sibling tools like plan_oauth_login and plan_oauth_wait by specifying the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

States the tool clears credentials locally and does not revoke at Notion end, providing context. Lacks explicit when-not or alternatives, but clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions finishing a pending login after user approval but doesn't disclose mutation behavior, error conditions, or return values. More detail needed for a tool involving network calls and user interaction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise and to the point, but lack of parameter details reduces effectiveness. Could be slightly longer to cover essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (OAuth flow, user interaction) and no annotations or output schema, the description is insufficient. Missing parameter explanation, success/failure behavior, and prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and description does not mention the timeout_ms parameter. No additional meaning beyond schema constraints. Parameter purpose and usage entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool completes a pending OAuth login after user approval, using specific verb 'Finish' and resource 'pending plan_oauth_login'. It distinguishes from sibling tools like plan_oauth_login and plan_oauth_logout.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (after plan_oauth_login with wait=false and user approval) but lacks explicit when-not-to-use or alternative guidance. The sibling tool list provides context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions authentication requirements but does not explicitly state whether the operation is read-only or has side effects. The context implies a read operation, but transparency is lacking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, but it sacrifices completeness. It front-loads the core purpose but omits parameter details, requiring the agent to infer from schema alone.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's 3 parameters and lack of output schema or annotations, the description is incomplete. It does not explain parameter constraints (e.g., limit default, service filtering), output structure, or pagination behavior, making it insufficient for reliable tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 3 parameters with 0% description coverage. The tool description fails to explain the meaning or usage of any parameter (query, limit, service). This is a significant gap for an agent to correctly invoke the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search') and the resource ('configured plan bank'), and lists specific fields returned (service, title, url, line, snippet). It also references sibling tool plan_get for comparison, helping to differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a prerequisite ('Requires plan_configure + NOTION_TOKEN') but does not explicitly state when to use this tool over alternatives like plan_get. The comparison to plan_get is implied but not expanded into a clear when-to-use or when-not-to-use guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavior. It states that the tool shows status and that browser OAuth opens automatically, which is a key side effect. However, it does not clarify whether the tool is read-only, what the exact output or status fields are, or if authentication state changes occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, presenting the purpose and a key guideline in a clear, front-loaded manner. Every word contributes meaningful information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameters, the description covers the basic purpose and the critical OAuth opening behavior. However, it lacks details on what exactly 'auth + workspace status' encompasses, such as specific status fields or return formats, making it less complete for an agent without further context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema coverage is 100%, so the description does not need to compensate. The baseline of 4 is appropriate; the description adds value by explaining the OAuth behavior, though it does not directly address parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Show' and resource 'auth + workspace status', clearly distinguishing it from sibling tools like plan_oauth_login and plan_get. The addition 'Call first' further clarifies its role as an initial status check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Call first', indicating when to use this tool. It also explains that end users need no CLIENT_ID because browser OAuth opens automatically, which helps differentiate from OAuth tools. However, it does not provide explicit when-not-to-use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the tool creates a local markdown file (an output file), which implies a side effect. However, it does not disclose whether it overwrites existing files, handles errors, or if the operation is idempotent. The description adds some behavioral context beyond the name but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences are perfectly concise, with the first sentence stating the core purpose and the second adding a prerequisite. No unnecessary words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (5 parameters, no schema descriptions, no annotations, no output schema) and the set of sibling tools (e.g., plan_configure, plan_get), the description is inadequate. It only covers basic purpose and a prerequisite, leaving parameter semantics and behavioral details completely unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation of the five parameters (path, title, dry_run, page_id, service). With 0% schema description coverage, the agent has no guidance on what each parameter does or how to use them. This is a critical gap for correct tool invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool exports a Notion plan to a local markdown file, specifying the verb 'export' and resource 'Notion plan (canonical)'. This distinguishes it from siblings like plan_get (retrieves plan data) and plan_migrate (moves plan).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite: 'Requires plan_configure + NOTION_TOKEN.' However, it does not provide guidance on when to use this tool versus alternatives, nor does it specify when not to use it. The prerequisite is useful but incomplete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses mutation, concurrency via etag, and error on missing spec. However, it does not explain how the update merges or replaces content, nor any side effects or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey core purpose and key usage tips. Could be slightly improved with bullet points or clearer separation of requirements, but overall no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite moderate complexity (10 params, no output schema), description omits many parameter semantics, return value, and error patterns beyond the missing spec case. Incomplete for an agent to fully understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description only explains about half of the 10 parameters (section, start_line, end_line, expected_etag). Missing details on service, new_markdown, title, dry_run, page_id, and occurrence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a 'surgical update' by section or line range, distinguishing it from full-replace operations. However, it could be more explicit in differentiating from sibling tools like plan_upsert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides specific guidance: prefer section over lines, pass expected_etag from plan_get, errors if no spec given. Prerequisites (plan_configure, NOTION_TOKEN) are listed. Lacks explicit comparison to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It does not detail side effects, error cases, idempotency, or what happens if the plan exists or not. The mention of 'upsert' is helpful but insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundant information. It front-loads the purpose and then adds requirements and matching detail. Efficient but could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and no output schema, the description is insufficient. It does not explain the mode parameter, dry_run behavior, or any return value. A more complete description is needed for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description adds minimal meaning beyond the schema: 'markdown string' and 'exact title'. Parameters like mode (enum with upsert/create_only) and dry_run are not explained, leaving significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create or update a plan from a markdown string.' It specifies the method (upsert by exact title under service page) and distinguishes from siblings like plan_get and plan_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions requirements ('Requires plan_configure + NOTION_TOKEN') and the matching condition ('by exact title'), but does not provide explicit guidance on when to use versus alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.