instadomain

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

With no annotations, the description explains that the domain is registered in the buyer's name, WHOIS privacy is enabled by default, and a Stripe checkout session is created. It lacks details on error handling or idempotency but is thorough for a purchase flow.

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 well-structured with a clear opening, prerequisites, notes, and argument list. It is slightly long but each sentence adds value, and critical info is front-loaded.

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 (11 params, no annotations), the description covers the entire workflow: prerequisite check, user confirmation, parameter explanations, post-call action, and return fields. It is fully complete for agent 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 the description provides an 'Args' section with clear explanations for all 11 parameters, including example formats (e.g., phone: '+1.5551234567', country: '2-letter ISO code'). This adds significant value beyond the schema.

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 'Start the purchase flow for an available domain via Stripe checkout.' It specifies the action, resource, and method, and distinguishes from siblings like check_domain (prerequisite) and buy_domain_crypto/buy_domain_mpp (different payment methods).

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 instructs to call check_domain first for price and user confirmation, and after the tool returns, to open the checkout_url via shell command. This provides clear when-to-use and post-call steps, preventing misuse.

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 carries full burden. Discloses two-step payment flow, phone format, country code, WHOIS privacy, and legal ownership rationale. Omits details on payment failure or timeouts but is otherwise thorough.

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?

Well-structured with numbered steps and sections. Slightly verbose but every sentence adds value. Front-loads purpose and workflow. Minor redundancy possible but overall effective.

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 11 params (10 required) and output schema, description covers workflow, prerequisites, post-payment polling, and rationale for registrant details. No gaps noted for the intended use case.

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%, so description adds value with examples and format hints (e.g., phone: +1.5551234567, country: 2-letter ISO). Most parameters have brief but adequate explanations; org_name notes optionality.

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 starts a purchase flow for a domain using USDC crypto payment (x402 protocol). It distinguishes from siblings like buy_domain (likely fiat) and buy_domain_mpp by specifying the payment method.

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 mandates calling check_domain first to get price and confirm. Details the two-step payment flow, alternatives for step 2 (Coinbase MCP or curl), and post-payment polling via get_domain_status. Provides clear when-to-use and prerequisites.

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?

Given no annotations, description fully discloses behavior: two-step flow, HTTP GET to pay_url, handling 402, creating SPT, charging, and polling. Also explains prerequisites like Stripe Business Network profile. No contradictions.

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?

Well-structured: opening purpose, then MPP explanation, step-by-step flow, requirements, args, returns. Every sentence adds value; no redundancy. Front-loaded with critical info.

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?

Complete for a complex flow tool: covers purpose, protocol details, procedure, prerequisites, all parameters, and return value (order_id, pay_url, price, etc.). No gaps given the complexity and presence of output schema.

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?

Description lists all 11 parameters with meaningful descriptions (e.g., domain example, country format, phone format, org_name optional). Since schema coverage is 0%, this adds essential context beyond type.

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 states 'Start the purchase flow for a domain via Stripe's Machine Payments Protocol (MPP)', specifying verb, resource, and method. It distinguishes from siblings (e.g., buy_domain, buy_domain_crypto) by highlighting MPP-specific payment flow.

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?

Clear two-step flow and requirement for an MPP-compatible client are stated. It mentions polling with get_domain_status after payment. Lacks explicit when-not-to-use, but context is sufficient.

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. Describes check behavior, return information, and subsequent workflow requiring user confirmation and payment selection. No contradiction.

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?

Well-structured with front-loaded main purpose, but the post-price instructions are lengthy. Every sentence is useful, but could be slightly more concise. Still efficient.

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 one parameter, no annotations, and presence of output schema, the description covers the tool's purpose, behavior, return type, and even links to next steps. Complete for its complexity.

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%, so description must add meaning. It explains the domain parameter fully: 'The full domain name to check (e.g. "coolstartup.com")'. Provides example and clarifies format.

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 'Check if a domain is available for purchase and get its price.' Uses specific verb+resource. Distinguishes from sibling tools like buy_domain, check_domains_bulk.

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 says 'Always call this before buying.' Provides step-by-step instructions after showing price, including how to choose payment method and which sibling tool to call next. Also suggests default based on configuration.

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?

Describes output summary and per-domain details, plus lookup method. No annotations, so description carries burden. Leaves out error handling and rate limits, but acceptable for a simple read 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 plus an args line. No wasted words. Purpose front-loaded.

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?

Covers input constraints, behavior, and output. Output schema exists so full return details not needed. Minor omission: no handling of invalid domains or exceeding limit.

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?

Adds 'max 50' constraint and clarifies domain names beyond schema's bare array type. Schema coverage is 0%, so description compensates well.

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 checks availability of up to 50 domain names in one call, distinguishing it from the singular check_domain sibling.

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?

Specifies use of fast RDAP lookups with no pricing, implying cost-free nature. Explicitly mentions max 50 domains. Lacks explicit when-not or alternatives but context from siblings suffices.

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 full burden. It discloses polling every 3 seconds up to 120 seconds and terminal states. However, it does not mention side effects, auth requirements, or whether it is read-only, which prevents a 5.

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 with two short paragraphs. The first sentence immediately states the purpose, and the rest provides necessary detail without fluff. Every sentence contributes 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?

The tool has an output schema (not shown but present), so return values need not be described. The description covers purpose, input, and behavior (polling). For a simple polling tool, this is complete and 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 coverage is 0% (no descriptions in schema). The description provides an example value for order_id and explains it is returned from buy_domain, adding meaning beyond the bare schema (type string). This is a clear improvement, earning a 4.

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 'Get the status of a domain purchase order' with a specific verb and resource. While the purpose is distinct from sibling tools like check_domain or buy_domain, it does not explicitly differentiate itself, so a 4 is appropriate.

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 after a domain purchase (order_id from buy_domain) and describes polling behavior, but it does not explicitly state when to use versus alternatives or when not to use it, earning a 3.

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 fully disclose behavioral traits. It only states the operation and prerequisites, omitting details like failure modes, idempotency, or side effects. This is minimal for a mutation tool.

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 brief and efficient, with purpose stated first, then prerequisite, then parameter explanations. Every sentence is useful and no repetition.

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 required params) and presence of an output schema, the description covers key aspects: purpose, prerequisite, parameter meanings. It could mention return format or error conditions but is largely 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?

The description explains both parameters: order_id is 'the order ID of a completed domain purchase' and transfer_token is 'token returned by verify_transfer_code.' Since schema description coverage is 0%, this adds essential meaning beyond type definitions.

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: 'Get the EPP/transfer authorization code for a completed domain purchase.' It specifies the verb, resource, and context, and distinguishes it from siblings like verify_transfer_code and request_transfer_code.

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 that a transfer_token from verify_transfer_code is required, indicating the prerequisite and proper sequence. It implies when to use this tool, though could be more explicit about not using it before verification.

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 behavioral disclosure burden. It reveals the side effect of creating a Stripe checkout session, which is useful. However, it does not discuss auth requirements, rate limits, or what happens on payment failure, leaving gaps.

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 front-load the main action and key side effect, with zero wasted words. The Args section is neatly formatted.

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 low complexity (one parameter, simple action) and existence of an output schema, the description covers the essential behavioral and parameter context. It could mention whether renewal is immediate or involves user payment flow completion, but it is largely complete.

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%, so the description must compensate. The description for order_id adds clear meaning ('The order ID of a completed domain purchase') and provides an example, which is valuable beyond the raw schema.

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 renews a domain for 1 additional year and creates a Stripe checkout session. This verb+resource combination is specific and distinct from sibling tools like buy_domain or suggest_domains.

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?

No explicit guidance on when to use this tool versus alternatives. It only mentions a prerequisite (order_id from a completed purchase) but does not compare with other domain tools or indicate when renewal is applicable.

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 the burden. It discloses that a code is sent to the registrant's email and that the tool initiates a verification flow. While it doesn't mention rate limits or code expiration, the behavioral implications are adequately conveyed for a simple code-sending tool.

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 and well-structured, with the core purpose and usage upfront, followed by parameter details. Every sentence adds value, with no redundant or irrelevant 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?

For a tool with one parameter and no annotations, the description is complete. It covers the purpose, the required input (order_id), and the integration with sibling tools (get_transfer_code, verify_transfer_code). The existence of an output schema further supports completeness.

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 0% description coverage, so the description adds significant meaning. It includes an Args section explaining order_id as 'The order ID of a completed domain purchase,' which provides essential context beyond the schema's type-only definition.

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: 'Start the transfer verification flow by sending a code to the registrant's email.' It uses specific verbs and resources, and distinguishes from siblings by noting the correct ordering relative to get_transfer_code and unlock_domain.

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 provides usage guidance: 'Always call this before get_transfer_code or unlock_domain.' It also outlines the full workflow, including asking the user for the code and then calling verify_transfer_code.

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; description mentions generating ideas and checking availability but does not disclose behavioral details such as number of ideas, real-time status, rate limits, or side effects. The agent is left with minimal information about the tool's behavior.

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 a clear action verb and example. No redundant information, and the structure is front-loaded with the main 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?

The tool is simple with one parameter and has an output schema, so the description covers basic purpose. However, it lacks usage guidelines and behavioral transparency, which are needed given no annotations. The description is minimally adequate but not complete.

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%, but the description's Args section adds meaning: 'A keyword or short business name (e.g. 'taskflow')'. This compensates for the lack of schema-level descriptions, providing useful context beyond the type.

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 verb 'generate' and resource 'domain name ideas', and specifies the action of checking availability. It distinguishes from sibling tools like check_domain which check specific domains, and buy_domain which purchases.

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?

No explicit guidance on when to use this tool vs siblings. The description implies a brainstorming use case but does not contrast with check_domain or buy_domain, leaving the agent to infer usage 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 provided, so description carries full burden. It discloses the state change (removing lock) but lacks details on potential failure modes, idempotency, or side effects. Adequate but not exhaustive for a mutation tool.

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 plus a clean Args list. No redundant information. Front-loads the purpose immediately. Every sentence 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?

For a simple unlock operation, the description covers the purpose, prerequisite, and parameter meanings. Output schema exists to define return structure. No gaps identified given the tool's simplicity.

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?

Description defines both parameters: order_id as 'order ID of a completed domain purchase' and transfer_token as 'Token returned by verify_transfer_code.' This adds meaning beyond the schema, which only provides types. Compensates for 0% schema description coverage.

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 action: 'Remove the registrar transfer lock.' It identifies the specific resource (domain transfer lock) and verb (remove). Differentiates from siblings by including prerequisite context.

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 prerequisite: 'Requires a transfer_token from verify_transfer_code.' This tells agents when to use this tool (after verification) and implicitly when not to (before obtaining token). Contextualizes among sibling tools dealing with transfer codes.

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?

The description discloses the token's 15-minute validity, which is important behavioral context. However, with no annotations provided, the description carries the full burden. It lacks details on error behaviors (e.g., invalid code), idempotency, or whether it consumes the code. The token validity is a positive, but missing failure modes reduce transparency.

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 and well-structured. It starts with a clear purpose, followed by usage flow instructions, and then parameter definitions in a bulleted list. Every sentence adds value with no fluff.

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 sibling tools and the existence of an output schema (not shown but implied), the description covers the entire workflow: when to call this tool, what it returns, and what to do next. It addresses the token lifetime and the relationship to request_transfer_code, get_transfer_code, and unlock_domain. No critical gaps remain.

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?

Despite 0% schema description coverage, the description explicitly defines both parameters: 'order_id: The order ID of a completed domain purchase' and 'code: The 6-digit code from the verification email.' This adds essential meaning beyond the schema's bare type and required status.

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: 'Verify the email code and get a transfer token valid for 15 minutes.' It uses a specific verb (verify) and resource (email code), and the return value is explicit. The tool is well-distinguished from siblings like request_transfer_code and get_transfer_code.

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 usage guidance: 'Call this after request_transfer_code and the user provides their code.' It also tells the agent what to do with the result: 'Pass the returned transfer_token to get_transfer_code or unlock_domain.' This clearly defines when to use and how to proceed.

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