mcp-server

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

No annotations provided, but the description discloses that it returns per-MB rate, that it's read-only reference info, and that it's not needed for purchase. Missing details on exact output format, but sufficient for a simple lookup.

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?

Four efficient sentences, each adding unique value. Front-loaded with core purpose, followed by usage caveats.

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?

Tool is simple with one param and no output schema. Description explains purpose, when to use, and context. Could optionally describe return format, but not required for safe 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?

Schema already provides 100% coverage with clear description and example for country_slug. Description reinforces 'Reference lookup only' but adds no new parameter meaning beyond 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 it provides reference info (per-MB rate) for a specific country, with a specific verb 'rate' and resource 'country'. It distinguishes from siblings like roamzy_list_countries (list all countries) and roamzy_estimate.

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 when to call (only if user asks about price for destination) and when not to call (during purchase), with reasoning that rates are reference info not a purchase gate.

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 fully covers behavioral traits: min top-up $20 backend rejection, pay currency mandatory, global eSIM functionality, anonymous mode claim_url with non-negotiable presentation, token spending limits, and post-payment polling requirement. 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?

The description is very long and includes a pitch script and exact phrasing, which, while helpful, makes it less concise. It could be shortened by referencing a separate prompt for the script. Information is valuable but not efficiently structured for quick agent parsing.

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 of ordering an eSIM with payment workflow, the description covers prerequisites (payment options), exact steps, error handling (rejection below min), post-payment actions (poll, get_esim), anonymous mode recovery link importance, and return values (msisdn, pay_url, user_facing block). No output schema exists, but return fields are described.

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 100%, and the description adds substantial meaning: amount_usdt (min 20, whole numbers, anti-dust), country_slug (reference tag, default esim-spain if no destination), pay_currency (mandatory, from payment options, never guess). Each parameter's business logic is explained 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 it 'Mint the user a Roamzy universal eSIM and fund it with the requested USDT amount'. It uses specific verb (mint/fund) and resource (eSIM), and the distinction from siblings like roamzy_estimate or roamzy_payment_options is implicit; the workflow explanation makes the tool's role in the ordering process unambiguous.

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 explicit when-to-use steps: never ask for country or MB, must call roamzy_payment_options first, only call after user picks stablecoin+network. States hard constraints (min $20) and workflow (1-5). Gives alternatives for pre/post steps (payment_options, order_status, get_esim).

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 burden. It correctly identifies the tool as a 'reference calculation' and informational, implying no side effects. However, it could explicitly state it is read-only or idempotent.

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 concise sentences: first defines purpose, second provides usage guidelines and exclusions. No wasted words, front-loaded with key 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 purpose and parameters are well-covered, but the description omits what the output looks like (e.g., returns a cost value in USDT). With no output schema, this is a notable gap, making the description adequate but not fully 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 coverage is 100%, with both parameters described in the schema. The description adds minimal new parameter information beyond restating usage context, so a baseline score of 3 is appropriate.

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 computes a reference cost in USDT for a given MB volume at a country rate. It distinguishes from sibling tools by emphasizing informational use only, not for purchase gating.

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 provides when to use (informational 'how much would X cost' queries) and when not to use (do not gate a purchase), with reasoning about user funding and per-MB billing.

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 fully discloses behavioral traits: it returns a payload, not an image; requires local QR generation; details anon-mode recovery steps; and warns against external services. Very transparent.

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?

Long but front-loaded with core purpose. Each section adds necessary procedural detail for correct invocation. A bit verbose but justified by complexity of post-processing.

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 simple parameter set and no output schema, the description covers the tool's purpose, result handling, edge cases (anon recovery), and even user follow-up instructions. Exceptionally 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 covers esim_id meaning 100%. Description adds context that the ID is internal and not shown to the user, reinforcing proper use. Baseline 3 plus extra value.

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?

Explicitly states 'Get a specific eSIM by id' and lists the fields returned. Distinguishes from sibling tools like list_esims and create_order by focusing on a single resource retrieval.

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 extensive context on when to use the tool and how to process the result (QR generation, recovery), but does not explicitly state when to avoid this tool in favor of 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 provided, the description carries the full burden. It discloses that the tool lists all 193 countries, is a rate card reference, and that the user gets one universal eSIM. While it could mention data freshness or that it returns all data at once, the given information is sufficient for a simple list 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 two sentences with zero wasted words. It is front-loaded with the core action and followed by context and usage guidance, making it highly 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?

For a tool with no parameters and no output schema, the description fully covers its role: a reference table for country rates. It provides enough context for an agent to invoke and understand its place in the flow.

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%, yielding a baseline of 4. The description adds context about what the list contains (countries and per-MB rates) but no parameter-level details are needed.

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 the specific verb 'list' and identifies the resource as '193 countries with Roamzy per-MB rates in USDT', clearly stating it is a reference table of roaming rates. It distinguishes from sibling tools by noting it's not a product catalog, making the purpose unmistakable.

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 specifies when to call this tool: 'only if the user asks «what countries are supported» or «show me rates»' and when not to: 'don't volunteer it during a purchase flow.' This provides clear context and exclusion guidance.

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 that it returns eSIMs with status/balance/msisdn, and importantly warns that msisdn is user-facing while id is internal. This is a useful behavioral trait beyond basic listing. However, no mention of permissions, rate limits, or pagination.

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 short sentences: first states purpose and output, second provides critical identifier guidance. Every word adds value; 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 no parameters, no output schema, and no annotations, the description is adequate. It explains what the tool does and important identifier usage. However, it does not explicitly state that all eSIMs are returned or mention ordering/filtering, though implied by lack of parameters.

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 exist; schema coverage is 100% trivially. Baseline 4 applies as per guidelines for 0 params. Description adds no parameter-specific info, but none is needed.

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 the action (List), resource (authenticated user's eSIMs), and returned data (status, balance, msisdn). Differentiates from sibling roamzy_get_esim by implying multiple eSIMs.

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 when/not or alternatives mentioned. Usage is implied by the description (listing all eSIMs), but lacks guidance on when to use this vs roamzy_get_esim or other tools.

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 carries full burden. It discloses the auto-minting behavior for anonymous mode and the implication that MCP connection does not guarantee an existing account. It does not detail other behaviors like error handling or rate limits, but for a simple get tool, this is adequate.

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: two sentences with a warning emoji. Each sentence provides essential information, no fluff. It is front-loaded with the 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 has no parameters, no output schema, and is a simple get, the description is surprisingly complete. It explains the key nuance about anonymous account creation and provides critical guidance for agents. No 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?

The input schema has 0 parameters, so schema description coverage is trivially 100%. The baseline for 0 params is 4. The description adds context about the account minting but not parameter-specific details, which are unnecessary.

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 current Roamzy account info', which is a specific verb+resource. However, it does not explicitly differentiate from sibling tools like 'roamzy_status' or 'roamzy_get_esim' based on functionality, though it does provide unique context about anonymous accounts.

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 gives explicit when-to-use and when-not-to guidance: it warns not to assume user has an account based on MCP presence, and explains that in anonymous mode the first call mints an account. It also directs to wait for successful return before making claims.

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 full burden. It discloses the status progression, the internal nature of order_id, and the proper way to refer to the eSIM via msisdn. This provides good insight into the tool's behavior and side effects.

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 front-loaded with the purpose and efficiently conveys the status progression, follow-up tool, and user guidance in a few sentences with 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?

The description covers the status progression, transitions to get_esim, and how to refer to the eSIM. While it lacks full output schema details, the key behavioral aspects are addressed adequately for a polling tool.

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 already describes order_id as 'Internal intent_id...' with 100% coverage. The description adds no new parameter-specific information beyond reinforcing that order_id is internal, which keeps it at baseline.

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 polls the status of a pending order and outlines the status progression, distinguishing it from sibling tools like roamzy_status and providing specific guidance for subsequent actions.

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 specifies when to use this tool (for pending orders) and when to transition to get_esim (after status=finished). It does not explicitly state when not to use it, but the context is clear and actionable.

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, but the description fully compensates by disclosing that data is pulled live from NowPayments with 1h cache, and includes fields code, display, fees_hint, and recommended. It warns against silent defaults. There is no contradiction with annotations.

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?

Every sentence earns its place. The description front-loads the critical warning and purpose, then explains source, cache, output fields, and UX guidance. It is well-structured and efficient for the amount of information conveyed.

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 parameters, no output schema, and no annotations, the description provides complete context: what it does, when to use, what it returns, and how to proceed after calling. It addresses the conditional use case and recommended UX, leaving no gaps.

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 tool has no input parameters, so the input schema provides no meaning. The description does not need to add parameter semantics, but it does describe the output structure (code, display, fees_hint, recommended), which is helpful. Baseline score of 4 for zero parameters is appropriate.

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 returns the list of stablecoin/network combinations, specifying its mandatory role before roamzy_create_order. It uses a specific verb ('Returns') and resource, distinguishing it from sibling tools like roamzy_create_order.

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 the tool is mandatory before roamzy_create_order when the user has not chosen a stablecoin+network, and outlines the recommended UX: ask the user which option to use, never silently default. This provides clear when-to-use and when-not-to-use guidance.

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 that earnings accrue in USDT, can be spent on eSIM traffic, requires identity linking for withdrawal, and works in anonymous mode. It also explains the referral chain compounding. This goes beyond basic expectations.

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 a single paragraph that efficiently conveys all necessary information. Each sentence adds value: purpose, commission detail, sharing instructions, earnings usage, return fields, and anonymous mode. It is front-loaded and not verbose.

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 absence of an output schema, the description lists all return fields (referral_code, referral_link, etc.) and explains them. It covers the tool's behavior comprehensively, including anonymous usage. Nothing seems missing for a parameterless tool.

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, so the baseline score is 4. The description adds no parameter information because none is needed. The schema coverage is trivially 100%.

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 YOUR Roamzy referral link + earnings.' It specifies the action (get), the resource (referral link and earnings), and provides detailed context about commissions, sharing, and return fields. This distinguishes it from sibling tools like roamzy_me, which likely focuses on general user info.

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 implicitly tells when to use: to obtain referral link and earnings information. It advises sharing the link 'whenever you recommend Roamzy.' While it does not explicitly exclude alternatives, the context is clear. No contradictory guidance is present.

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 the key behavioral trait of checking pause flags and instructing backup behavior. The output structure is not described, but for a status check this is sufficient.

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: first sentence states purpose, second gives critical usage rule. Perfectly front-loaded and 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 the tool has no parameters and no output schema, the description fully covers what the tool does and how to use it. No gaps in information.

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 input schema has zero parameters, so schema coverage is 100% trivially. The description adds no parameter info, but baseline for 0 parameters is 4 as per instructions.

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 'Check' and the resource 'Roamzy API status, including agent pause flags'. It distinguishes this tool from siblings like roamzy_create_order or roamzy_list_countries by focusing on status checking.

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 agents MUST call this before purchase attempts and back off if purchases_paused=true. This provides clear when-to-use guidance, though it does not explicitly compare 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?

No annotations provided, so description carries full burden. It discloses exactly what the tool returns (Telegram bot, email, recovery procedure, etc.) and why it is preferred over web search (lookalike companies). 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?

Description is front-loaded with a warning and then bullet-point-like list of returned items. Slightly long but each sentence provides value; 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?

For a zero-parameter, no-output-schema tool, the description fully covers the tool's purpose, behavior, and returned content. It is complete enough for an AI agent to understand and invoke correctly.

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?

Tool has 0 parameters, so schema coverage is 100% and no param info needed. Baseline 4 applies; description adds no param details but none are required.

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 explicitly states the tool returns official Roamzy support info, with a clear verb ('returns') and resource. It distinguishes from web-searching and sibling tools like roamzy_me or roamzy_order_status.

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 explicit when-to-use instructions: 'CALL THIS instead of web-searching when the user asks how to contact...' and lists specific queries. Also warns against using general knowledge.

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