Message a Business

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

The description discloses more than the readOnlyHint/idempotentHint/destructiveHint annotations: it explicitly says no message is sent and no state changes, that it is free and sub-100ms, that the same gate re-runs at send time, that it does not check voice recording consent, and that it never delivers anything. This gives the agent an accurate mental model of 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?

The description is front-loaded with the core purpose and well organized with WHEN TO USE, WHEN NOT TO USE, COST, LATENCY, and examples. It is slightly padded by duplicating cost/latency info and referencing check_booking_link, a non-sibling tool, but the examples and clear sections earn their length.

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 6-param regulated-send tool with no output schema, the description fully compensates: it explains the outcome semantics (legal=true/false, named rule, remediation), runtime behavior, cost, latency, and exact usage boundaries. An agent has everything it needs to select and invoke the tool 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?

Schema covers all 6 parameters at 100%, so the baseline is 3. The description adds practical value with concrete example calls showing how to populate recipient_id, content, channel, message_type, and country_code, and when to omit auto-inferrable fields. It also demonstrates chaining to send_message after a successful check, which helps an agent 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 states a specific verb and resource: it runs the exact TCPA/GDPR/CASL/CAN-SPAM/10DLC compliance gate used by send_message and call_business, but in preview mode with no side effects. It clearly distinguishes itself from sibling tools by naming send_message and call_business and framing itself as a pre-flight 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?

Provides explicit WHEN TO USE and WHEN NOT TO USE sections, names the exact follow-up tools (send_message, call_business), and gives exclusions such as two-party recording consent. It also warns that legal=true is not permanent because the gate re-runs at send time, which is essential 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?

Annotations already declare readOnlyHint and idempotentHint, so the description is not needed for basic safety. It adds substantial behavioral context: the network is small and mostly sample data, demo entries are named [DEMO] and flagged is_demo, and availability_window is accepted but not applied and the response carries availability_window_applied: false. No contradiction with annotations exists.

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 detailed but well-organized and every section earns its place: core function, critical demo-data warning, example mappings, explicit usage rules, and operational notes. Important caveats are front-loaded before the examples and when-to-use guidance.

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 output schema and non-trivial nested parameters, the description covers the essential invocation context, demo-data caveat, and non-applied availability_window semantics. It could go slightly further by describing the shape of a ranked result beyond the is_demo flag, but the guidance is sufficient for an agent to call and interpret results correctly in most cases.

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?

Although schema coverage is only 50%, the description's example queries add concrete mappings from natural-language requests to JSON arguments for vertical, location, and capability. The schema already explains availability_window's non-applied behavior and provides defaults/constraints for max_results and radius_miles; remaining params like price_band are self-explanatory from their schema structure.

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 states a specific action and resource: 'return ranked candidate businesses from our supply network' given explicit criteria. It also distinguishes itself from a general directory/browsing tool and from tools like verify_business by explicitly ruling out use when a verified SMB identifier is already held.

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 both explicit WHEN TO USE and WHEN NOT TO USE guidance, along with three example user queries mapped directly to call arguments. It names alternatives such as schedule_appointment and send_message and states conditions for preferring them, leaving little to inference.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false; the description adds valuable context by promising that replies are matched exactly and never guessed, so the data belongs to the end-user. Costs and latency are also disclosed. 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?

The description is well-structured with distinct sections: overview, examples, WHEN TO USE, WHEN NOT TO USE, cost, and latency. The core purpose is front-loaded and each section earns its place with actionable information, though the example queries add some length.

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 read-only tool with three well-described parameters and no output schema, it adequately states what data is returned, when to call it, and a rate limiting caution. It doesn't detail return structure or errors, but gives the agent enough to select and use the tool 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?

Schema description coverage is 100%, so the schema fully documents each parameter. The description contributes a usage example and notes conversation_id is preferred, but it does not add substantial meaning beyond what the schema already says about reference, business_number, and conversation_id.

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 starts with a specific verb and resource: 'Read a two-way conversation thread you started,' and enumerates exactly what it returns: state, every message exchanged, and reply count. This clearly differentiates it from siblings like get_status or get_outcome because it is uniquely about conversation threads.

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?

An explicit WHEN TO USE section states it should be called after send_message returns a conversation_id, in order to poll for the business's reply. The WHEN NOT TO USE section adds a real constraint: don't poll more often than every 10 seconds. It doesn't explicitly recommend an alternative sibling, but the trigger condition is concrete and 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial operational context: cost ('free - no key required'), latency (~50ms), and a state precondition (do not call before completion). No contradiction with annotations. The extra details go well beyond what the annotations already provide.

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 compact and well-organized: a one-sentence purpose followed by labeled WHEN TO USE, WHEN NOT TO USE, COST, and LATENCY sections. Every sentence earns its place and the main purpose is front-loaded. Minor mojibake in the dash appears to be an encoding artifact rather than a content flaw.

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 single-parameter read tool with no output schema, the description covers purpose, prerequisite state, cost, latency, and hints at return contents ('cost and reason codes'). It does not describe error cases or the exact response shape, but those gaps are minor given the tool's simplicity and annotations.

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 one required parameter, operation_id, with 0% schema description coverage. The description implies that operation_id identifies the operation whose outcome is being retrieved and that it should come from a completed operation, but it never explicitly defines operation_id or its source. It partially compensates for the lack of schema descriptions but could be more direct.

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 states a specific verb ('Retrieve'), a specific resource ('final OutcomeReceipt'), and a scope ('completed operation'), making the tool's function immediately clear. It also implicitly distinguishes itself from get_status by positioning this as the terminal retrieval step. No tautology or ambiguity.

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?

Contains explicit WHEN TO USE and WHEN NOT TO USE sections. It names get_status as the prerequisite and alternative, specifies that the tool should only be called after get_status returns success/failure/partial, and warns against calling while operations are pending/executing. This is ideal routing 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?

The description adds meaningful behavioral context beyond the annotations: it discloses a 10-second minimum polling interval, notes the tool is free and requires no key, and states approximate latency. These are operational details an agent needs that annotations do not provide.

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 compact and well-structured, with sections for WHEN TO USE, WHEN NOT TO USE, COST, and LATENCY. Every sentence adds useful information and the most important usage guidance 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?

For a simple one-parameter polling tool, the description is nearly complete: it identifies the operation, gives usage guidance, and provides cost/latency. It does not enumerate the possible state values returned, but the purpose and polling behavior are sufficiently clear without an 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?

The input schema has no parameter description, so the description carries the burden of explaining operation_id. It does mention that operation_id identifies the async operation to poll, which is useful, but it does not describe any format, source, or validation constraints. Given only one parameter, this is adequate but not rich.

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 queries the current state of an in-flight async operation by operation_id, using a specific verb and resource. It does not mention sibling alternatives like get_outcome, so it lacks explicit sibling differentiation, but the purpose is 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?

The description provides explicit WHEN TO USE and WHEN NOT TO USE guidance, including polling frequency limitations and directing users to webhook delivery for real-time updates. This gives clear context for when to choose this tool over 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral detail: it returns min/max ranges when cost depends on channel or outcome, explicitly disclaims an accuracy percentage, and notes the tool is free. This goes well beyond the structured metadata.

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 front-loaded purpose, followed by examples, usage rules, and cost note. Every section earns its place; the content is detailed without being repetitive or bloated.

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?

There is no output schema, so the description carries the burden of explaining return values. It covers the main return categories, exact vs. range behavior, the cost_range caveat, and the free nature of the tool. This is sufficient for an agent to decide whether to call the tool and what to expect.

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 50%, and the description compensates with concrete examples showing how to pass 'operation' and 'params'. It demonstrates the shape for send_message and schedule_appointment, but it does not enumerate valid operation values, leaving some ambiguity.

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 states a specific verb ('Return an expected cost estimate, latency estimate, and success-probability estimate') and resource ('for a proposed call before execution'). It clearly distinguishes this preview tool from execution tools like send_message, and explains the exact vs. range behavior for prices.

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 WHEN TO USE ('before any operation... under a budget constraint') and WHEN NOT TO USE ('do not use in a hot loop... cache the result for at least 60 seconds'). It does not explicitly name an alternative tool, but the exclusion of hot-loop usage and the 'before execution' framing gives clear operational 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior, but the description adds valuable context: it runs 6 internal checks, reports pass count, does not probe each tool individually, has ~200ms latency, is free, and has a rate-limit caution. No contradictions with annotations; description enriches them substantially.

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 main description is front-loaded with the essential purpose, and each additional section (example, when to use, when not to use, cost, latency) earns its place by helping an agent decide and call correctly. No filler or redundant repetition of schema data.

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 rich annotations, the description is fully complete. It explains what the tool checks, how to call it, when to use it, and its operational constraints, so an agent has everything needed to invoke it 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?

The tool has zero parameters, so the schema already covers everything. The description adds an example call 'self_test({})' and clarifies that no arguments are needed, which is sufficient for this parameterless 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?

States a specific verb and resource: 'runs 6 internal checks and reports how many passed,' and explicitly distinguishes itself from sibling tools with 'it does NOT probe each tool individually.' This makes it immediately clear what self_test does and what it does not.

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 guidance: 'at agent startup, before high-stakes task sequences, or after receiving unexpected errors,' and a clear WHEN NOT TO USE constraint: 'Do not call more than once per minute in production.' Also gives a matching example user query, leaving no ambiguity about appropriate invocation.

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?

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the non-bypassable compliance gate, runtime rejection with a structured compliance_violation receipt, channel abstraction with fallback, the refusal of future send_at_iso values, cost, latency, and the need to call get_outcome for results. This gives the agent a strong mental model of the tool's side effects and failure modes.

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 long but well-structured with bold section headers (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY, EXECUTION) and concrete examples. The front-loaded purpose sentence and scannable sections make the length acceptable, though a few details like the exact cost range could be deferred to preview_cost without losing essential 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 8 parameters, nested objects, compliance rules, and no output schema, the description covers usage constraints, channel behavior, scheduling limitations, and alternative tools. It does not describe the success receipt or the return shape from get_outcome, and the consent_record_id omission from the schema leaves a hole, but overall the agent has enough context to invoke the tool correctly in most cases.

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 adds meaningful context to message_type (marketing requires consent), channel behavior, and compliance-related restrictions. However, it repeatedly references consent_record_id as a required input for marketing, yet this parameter does not appear anywhere in the input schema, creating a semantic mismatch. With 63% schema coverage, the description partially compensates but leaves this gap unresolved.

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 states a specific verb and resource: 'Send a message on behalf of an agent's user or an SMB across WhatsApp, SMS, email, or voice,' and enumerates the five message types. It further distinguishes itself from the sibling tool send_transactional_confirmation by explicitly excluding OTPs and critical transactional confirmations. This makes the tool's scope and identity 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?

The dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections give concrete scenarios (booking confirmation, reply to customer, quote follow-up, reminders, opted-in marketing) and explicit exclusions with the named alternative send_transactional_confirmation. It also cautions against bulk/cold outreach, covering both positive and negative selection criteria.

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 annotations declare idempotentHint=false, but the description says 'Idempotent transactional messages' and states that replaying the same key returns the original receipt and is not re-executed. This is a direct annotation contradiction and per rubric scores 1. The description does add useful context about channel fallback and honest failure, but the idempotency contradiction is severe.

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 organized into a short definition, a concrete example, WHEN TO USE, WHEN NOT TO USE, COST, LATENCY, and EXECUTION. This is well structured and front-loaded. The 'do not use for marketing' point appears twice and the text contains a mojibake artifact, but overall the length is justified by useful operational context.

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 idempotency, channel fallback, honest failure behavior, cost, latency, and directs the agent to get_outcome for the result, which is valuable for a tool with no output schema. However, it does not define the result or error shape, and the parameter example contradicts the schema, leaving an agent without a reliable request template. For a tool with 5 parameters and nested objects, this is 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 description coverage is only 40%, so the description needed to compensate. The example call uses a recipient object with id_type and id_value, while the input schema defines recipient as an object with phone_or_email (and optional name). Additionally, the booking_confirmation data example uses business_name while the schema's data description uses smb_name. These mismatches are actively misleading. The idempotency_key and confirmation_type context is helpful, but the wrong examples undermine correctness.

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 identifies the resource as transactional messages (OTP, booking confirmation, payment receipt, cancellation notice) and the example query shows exactly how to invoke it. The WHEN NOT TO USE section separates it from marketing and conversational messaging, making it distinguishable from send_message. The only small weakness is that the opening is a noun phrase rather than an explicit verb, but the tool name and example make the action 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?

Explicit WHEN TO USE (messages that MUST be delivered reliably) and WHEN NOT TO USE (marketing or conversational) are present. The exclusions are specific enough for an agent to avoid misrouting, though it does not name the sibling tool that should be used instead. The guidance is clear but not maximally explicit about 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses that the tool does not contact the business, which is a meaningful behavioral trait. It also outlines what data is returned and includes cost and latency context, all consistent with the 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?

The description is well structured and front-loaded: purpose first, then the key non-contact caveat, a relevant example, and clear WHEN TO USE/WHEN NOT TO USE sections. Every section serves a purpose, with no redundant filler.

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 lookup tool with no output schema, the description explains what the tool returns, when to use it, when not to use it, and provides a full example invocation. It lacks an explicit statement that capability_to_verify is optional and does not describe failure behavior, but these are minor gaps given the annotations and the example.

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. It partially does via a concrete example mapping a user query to smb_id and capability_to_verify, and the opening sentence references capabilities. However, it does not define valid values for capability_to_verify, clarify the format of smb_id, or note that capability_to_verify is optional.

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 states a specific verb ('look up') and resource ('a business in our supply network'), then enumerates what the lookup returns: contact channels, capabilities, and last verification time. It explicitly labels itself a 'DIRECTORY LOOKUP' and contrasts with contacting the business, and the WHEN NOT TO USE section distinguishes it from find_business.

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 WHEN TO USE and WHEN NOT TO USE rules, including a concrete alternative tool (find_business) and a temporal condition (results within the last 24 hours are already verified). This gives an agent clear decision criteria for selecting this tool over siblings.

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