Agent Broker

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

The description adds significant behavioral context beyond annotations: async execution with a call handle, polling via get_outcome, cost ($0.5 per call), latency (~45s), and compliance gate for recording consent. However, it does not elaborate on the destructiveHint=true annotation—what specifically is destroyed or irreversible—so it falls short of fully transparent on that dimension.

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 clear headers (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY, EXECUTION) and front-loaded with the core purpose. However, phrases like 'THE differentiated capability' are slightly promotional and the length could be trimmed to only essential facts, though no section is redundant.

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 complexity (aspects: real-world phone call, async, compliance, B2B-only), the description covers usage guidance, cost, latency, execution model, and retrieval of results. It lacks explicit failure-mode handling (e.g., what happens if the call fails) but is otherwise reasonably complete for an async tool with no 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?

Schema description coverage is high (86%) and the schema already documents each parameter (e.g., smb_id vs business_phone, extract_fields, max_duration_seconds). The description adds only high-level guidance ('Give a plain-language objective') and does not provide deeper parameter-specific semantics beyond what the schema already contains.

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 verb and resource: 'Place a conversational voice-AI phone call to a business on a consumer's behalf and return a structured answer.' It also explicitly differentiates from siblings by targeting long-tail SMBs with no API/booking page, making it distinct from import_booking_url and schedule_appointment.

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' sections. It names concrete alternatives (import_booking_url, schedule_appointment) for businesses with booking URLs, and excludes consumer calls and marketing. This goes beyond implied usage to give clear decision rules.

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

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

Beyond the annotations (all false booleans), the description discloses validation, enrichment hooks, deduplication, insertion into CRM/booking pipeline, cost, latency, and the execution mode (sync_fast with result retrieval via get_outcome). This provides substantial behavioral context not available in structured fields.

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 clear sections (description, example, when to use/not use, cost, latency, execution). It is informative without being redundant, and every section serves a purpose for correct agent usage.

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 output schema and low parameter descriptions, the description covers purpose, usage, cost, latency, execution, and provides an example. It also directs the agent to get_outcome for results, making it operationally complete for a lead capture 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?

With schema description coverage at 33%, the description compensates by providing a concrete example call showing how to populate smb_id, prospect (name, phone, email), and source. It also implicitly indicates that the tool handles a single prospect, not bulk. However, it does not elaborate on fields like consent_record_id beyond the schema's own description.

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 function: structured intake of a prospect into an SMB's funnel with validation, enrichment, and deduplication, inserting into CRM or booking pipeline. It explicitly distinguishes from schedule_appointment for confirmed bookings, making its purpose 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 and WHEN NOT TO USE sections, naming schedule_appointment as an alternative for confirmed bookings and excluding bulk list imports. This gives the agent clear direction on tool selection.

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 behavioral context beyond the annotations: it discloses cost ($0.2), latency (~2000ms), default async execution, and directs users to get_outcome for results. This complements the destructiveHint annotation without contradicting it. It doesn't detail side effects like ticket creation or permission requirements, but it provides meaningful extra context.

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 structured with a purpose statement, example, WHEN sections, and cost/latency/execution bullets, making it scannable. It is somewhat long but each section adds value. The example query, however, contains an error and could be simplified, slightly reducing efficiency.

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 key aspects: purpose, usage constraints, cost, latency, and async behavior. Yet it does not explain the return value or success criteria (beyond referencing get_outcome), nor does it clarify the priority parameter. Given the schema's complexity (nested objects and enums) and no output schema, this is a moderate gap.

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 partially explains parameters by describing the context bundle (transcript, prior actions, identifiers, recommended next step), which maps to the context object. However, schema coverage is 0%, and the description omits smb_id and priority semantics. More critically, the example is inconsistent with the schema: it uses 'agent_blocked' (not in the reason enum) and 'summary' instead of the required 'context' field, which can mislead the agent.

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 function: 'Hand off an in-flight task to a human operator with a full context bundle.' It is specific about the action (handoff) and resource (in-flight task), and the included example queries further clarify the intended use. It is easily distinguished from sibling tools like send_message or get_outcome.

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 sections, stating to escalate only after automated resolution attempts and listing valid conditions such as customer-requested or human judgment. However, it does not name a specific alternative tool for automated resolution, so it falls slightly short of fully explicit 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 annotations already declaring readOnly, idempotent, and non-destructive behavior, the description adds extra context: it returns only curated, verified, transactable businesses, not raw results, and includes cost and latency details. This exceeds the bare annotation hints without contradicting them.

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 purpose sentence, examples, when-to-use/not-use, and cost/latency. Every section adds value and is front-loaded with the core behavior. No fluff or 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?

There is no output schema, so the description should explain the return shape, but it only says "ranked candidate SMBs" without detailing fields or pagination. For a moderately complex tool with nested parameters, the description covers usage well but leaves the output representation under-specified.

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

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

Schema description coverage is only 33%, so the description must compensate. It names the criteria (vertical, location, capability, price band, availability window) and provides examples for vertical, location, and capability, but does not explain the semantics of price_band, availability_window, max_results, or radius_miles beyond their names. This is partial but not complete compensation.

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 opens with a clear verb-resource relationship: "return ranked candidate SMBs from the verified supply network." It explicitly differentiates itself from a raw directory and mentions it should be called before schedule_appointment or send_message, distinguishing it from sibling tools.

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 sections, including concrete examples and exclusions like "Do not use when you already have a specific verified SMB identifier." It also gives three user query examples with mappings to parameters, offering clear guidance on 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds timing constraints (only after completion), result contents (cost and reason codes), and cost/latency metrics, which go beyond 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 concise and well-structured, with the purpose upfront and clear labels for usage and cost. No extraneous content.

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 single-parameter tool with no output schema, the description covers when to use, what to expect, and cost/latency. It could mention the origin of operation_id, but overall it's sufficient.

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

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

Schema has zero description coverage for operation_id, and the description does not explicitly define the parameter. The context implies it identifies the operation, but the description should explicitly state this to compensate for the schema gap.

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

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

The description clearly states the tool retrieves the final OutcomeReceipt for a completed operation, with a specific verb and resource. It distinguishes from siblings by specifying 'after completion' and mentioning cost and reason codes.

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, naming get_status as the prerequisite and alternative. This is exemplary guidance for tool selection.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context on cost, latency, and polling frequency, which goes beyond 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 structured into clear sections (purpose, when to use, when not to use, cost, latency) and is front-loaded with the main purpose. Every sentence provides distinct value with no redundancy.

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

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

For a simple single-parameter tool with strong annotations, the description covers usage, cost, latency, and rate limiting. However, it does not describe the response format or possible statuses, which would be useful since no output schema is provided.

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%, and the description only mentions 'operation_id' without explaining its format, origin, or how it relates to async operations. The parameter name is self-explanatory, but the description adds little semantic 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?

The description clearly states 'Query the current state of any in-flight async operation by operation_id' with a specific verb and resource. It distinguishes itself from sibling tools like get_outcome by focusing on polling in-flight operations.

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 and WHEN NOT TO USE sections provide clear context, including polling scenarios, rate limiting, and a webhook alternative. This fully meets the guideline 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 description discloses async-by-default execution, cost ($0.03 per inbound), latency (~3000ms), and that result retrieval requires get_outcome. These go beyond the annotations (which only give hints like readOnlyHint=false) and provide actionable behavioral context. No contradiction exists 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 with clear sections (example, WHEN TO USE, WHEN NOT TO USE, cost, latency, execution). Each section conveys valuable information. The example, however, is a structural flaw because it contains an incorrect parameter name, reducing the overall quality from a 5.

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 6 parameters, a nested sender object, and no output schema, the description is incomplete. It does not explain common parameters like smb_id, raw_message, or inbound_channel, nor the structure of the outcome. While async behavior is mentioned, the lack of return value guidance and poor param coverage leaves significant gaps for an agent.

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 coverage is only 17% (just routing_rules), leaving most parameters undocumented. The description compensates with a concrete example, but that example is actively misleading: it uses 'channel' instead of the schema's 'inbound_channel' and omits the required 'smb_id'. This misdirects the agent and could cause invocation errors.

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 function: 'Receive, classify, and route inbound messages on behalf of an SMB.' It specifies intent classification (booking request, cancellation, inquiry, complaint) and routing to handlers or escalation paths, making it distinct from outbound or lead-capture siblings. The WHEN NOT TO USE clause explicitly excludes outbound communications, reinforcing its purpose.

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 sections, giving clear context for inbound triage across channels like SMS, email, voicemail, and web forms. It also names an alternative step: 'use get_outcome to retrieve result' for async execution, which guides the agent on follow-up.

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 idempotentHint annotation, the description adds concrete operating details: idempotent behavior ('calling twice returns the same smb_id'), cost ($0.005 per_call), latency (~600ms), and how the smb_id is used downstream. This exceeds annotation coverage without 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?

The description is well-structured with a clear opening sentence, example queries, and distinct WHEN TO USE / WHEN NOT TO USE / COST / LATENCY sections. Every sentence serves a purpose, and the header-based layout makes it easily scannable.

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 7-parameter tool with no output schema, the description covers the tool's purpose, usage patterns, exclusions, supported platforms, cost, latency, and the nature of the returned smb_id. It provides sufficient operational context for an agent 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?

Schema coverage is 100%, so baseline is 3. The description adds practical value with example parameter mappings (e.g., booking_url + vertical) and clarifies inference behavior for vertical and business_name auto-extraction. This pushes it above 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 opens with a specific verb+resource: 'Turn ANY public booking URL ... into a callable smb_id you can immediately use'. It names the supported platforms and explicitly distinguishes the tool's import function from downstream tools like schedule_appointment, send_message, and capture_lead.

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, including example user queries and the alternative tool (find_business) for non-URL cases. This clearly guides the agent on when to choose import_booking_url.

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, idempotentHint=true, and destructiveHint=false, and the description adds no contradiction. It further discloses the accuracy SLO (±5%), per-call cost ($0.001), expected latency (~100ms), and caching advice, enriching behavioral context beyond what annotations 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 well-structured with a summary, accuracy SLO, example queries, usage guidelines, cost, and latency. Every section provides useful information, is front-loaded with the core purpose, and contains 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 tool with no output schema, the description explains the return values (cost, latency, success-probability) and provides accuracy, cost, and latency details. It also covers when to use and when not to use, making the description self-sufficient for agent invocation without additional context.

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

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

The schema describes 'params' as the request body to pass, and the description supports this with concrete examples for send_message and schedule_appointment. The 'operation' parameter lacks an explicit description, but examples imply it corresponds to sibling operation names, partially compensating for the 50% schema 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?

The description clearly states the tool returns cost, latency, and success-probability estimates for a proposed call before execution. It distinguishes itself from sibling execution tools by positioning it as a pre-flight preview, reinforced with concrete example queries mapping user intents to specific operation calls.

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 includes explicit WHEN TO USE and WHEN NOT TO USE sections, specifying it is for budget-constrained decisions and advising against hot looping with a 60-second cache recommendation. This provides clear, actionable guidance beyond simply invoking the tool.

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 indicate destructive and non-read-only behavior, and the description adds valuable context: it routes through the SMB's native booking system with fallback to voice AI or web form, provides cost and latency estimates, and explains async execution with get_outcome for results. This goes well beyond 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 with a summary, examples, when-to-use/not, and cost/latency/execution sections. Every sentence adds value, and the front-loaded summary gives immediate purpose. The organization enhances readability without superfluous text.

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 7 parameters, nested objects, no output schema, and modest annotations. The description covers high-level behavior, fallback mechanisms, and execution mode, but does not explain how to construct the requested_time object or what the return structure looks like. It also does not detail the 'hold' action, leaving some gaps for a tool this complex.

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 14%, and the description does not compensate by explaining most parameters. The examples map a few fields (smb_id, action, service) but do not clarify requested_time, customer, notes, or the required existing_appointment_id for reschedule/cancel. This leaves significant ambiguity for the agent.

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 handles availability lookup, hold, confirm, reschedule, and cancel appointments for an SMB. It uses specific verbs and resources, and the example queries clarify the intended actions. It distinguishes from siblings by focusing on appointment scheduling specifically.

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 'WHEN TO USE' and 'WHEN NOT TO USE' sections explicitly provide context and exclusions, including requiring a verified smb_id and calling find_business/verify_business first. It also names alternatives for verification, giving clear guidance on when not to use this tool.

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 behavioral details beyond the annotations: rate limiting ('Do not call more than once per minute'), cost, latency (~200ms), and that it checks 'supply network size.' These are operational traits not present in the readOnlyHint or idempotentHint annotations, giving the agent richer 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 well-structured with front-loaded purpose, then usage guidance, and operational details. Each section (description, example, when-to-use, when-not-to-use, cost, latency) adds distinct value without redundancy, and the formatting improves scannability.

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 diagnostic tool, the description is fully complete: it defines the probe's function, mentions integration verification, gives usage timing, sets rate limits, and notes cost/latency. No output schema is present, but the tool's simplicity means this is 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 tool has zero parameters, so the baseline is 4. The description correctly omits parameter details as there are none, and the empty schema leaves no 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 clearly defines the tool as a 'Live capability probe' that verifies service health, reachability of operations, and supply network currency. This specific verb+resource phrasing immediately distinguishes it from sibling tools like send_message or call_business, which perform actual operations.

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 and WHEN NOT TO USE sections provide clear guidance: use at startup, before high-stakes sequences, or after errors; avoid more than once per minute. This also includes a concrete example user query, making the tool's application obvious.

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 critical behavioral traits beyond the generic annotations: the non-bypassable compliance gate that rejects unconsented marketing with a compliance_violation receipt, channel abstraction with fallback, cost from $0.02, latency ~800ms, sync_fast execution, and instruction to use get_outcome for results. These are significant operational details not inferable from annotations or schema.

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 sections for examples, when to use, when not to use, cost, latency, and execution. Each section adds value, though there is minor repetition of the consent verification statement. The mismatched examples slightly detract from overall structure, but the organization is otherwise clear 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?

The description covers a wide range of context: compliance, channel fallback, usage boundaries, cost, latency, and execution flow. However, it introduces consent_record_id as essential for marketing but does not include it in the schema, leaving a critical gap for the agent. The example parameter mismatches also undermine completeness. Without an output schema, the description points to get_outcome but does not clarify how to interpret the compliance_violation receipt. These gaps make it only partially 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?

The prose explains message types and consent requirements, adding meaning beyond the schema. However, the example calls use parameter names that directly contradict the schema: 'recipient_id' vs. 'recipient', 'channel_preference' vs. 'preferred_channel', and 'message' vs. 'content'. Additionally, consent_record_id is mentioned as required for marketing but is completely absent from the input schema. These inconsistencies can mislead an agent into constructing invalid calls, and with only 40% schema coverage, the description fails to reliably compensate.

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 core function: 'Send a message on behalf of an agent's user or an SMB across SMS, email, or voice.' It also differentiates from sibling tools by explicitly naming send_transactional_confirmation as the alternative for OTPs/critical confirmations. The message types and compliance gate are described, making the tool's purpose 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?

WHEN TO USE lists concrete scenarios (confirm booking, reply to customer, follow up on quote, appointment reminders, consented marketing). WHEN NOT TO USE explicitly excludes OTPs/critical transactional messages and directs to send_transactional_confirmation, and warns against bulk/drip/cold outreach. This provides strong guidance on when to use this tool versus 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?

The description claims 'Idempotent transactional messages' while the annotations set idempotentHint=false, a direct contradiction. This is an annotation contradiction and severely undermines trust in the behavioral description.

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 structured with clear sections, but the EXAMPLE USER QUERIES section is lengthy and contains incorrect parameter usage. It could be shorter and more accurate, making the overall description less concise than it should be.

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 cost, latency, execution mode, and points to get_outcome for results, but lacks complete parameter details (especially for 'data') and includes a misleading example. Given no output schema, more complete and accurate parameter guidance would be needed.

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?

With only 25% schema coverage, the description needed to clarify parameters, but it instead provides an example using wrong parameter names ('recipient_id', 'channel_preference') and an invalid confirmation_type value ('booking' instead of 'booking_confirmation'). This actively misleads agents about the actual 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 identifies the tool as sending transactional messages (OTPs, booking confirmations, payment receipts, cancellation notices) with a specific verb and resource. The 'WHEN NOT TO USE' section further distinguishes it from marketing and conversational messages, making the purpose 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 dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections, explicitly stating to use for reliable transactional messages and not for marketing or conversational messages. It also mentions retrieving the result via get_outcome, offering clear practical 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 discloses cost ($0.02 per call), latency (~500ms), and the fact that a live capability probe is performed, adding behavioral context beyond the annotations. The 'live probe' implies an external interaction with the business's channel, which is useful for the agent to anticipate side-effects. This does not contradict the readOnlyHint.

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 concise main sentence, an illustrative example, explicit usage guidance, and cost/latency details. Every sentence adds value, and the information is front-loaded and easy to parse.

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 purpose, example, when/not to use, cost, and latency, which is comprehensive for a tool with no output schema. However, it does not explicitly state the return value or result format (e.g., boolean), which would be useful for an agent to know what to expect after invocation.

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

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

With 0% schema description coverage, the description compensates by providing an example query that maps user intent to parameter values, clarifying that smb_id is the identifier and capability_to_verify is the service to confirm. However, it does not enumerate valid capabilities or specify formats beyond the example, 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 clearly states the tool's function with specific verbs: 'Confirm that an SMB is real, currently operating, and capable of the requested service' and 'Performs a live capability probe against the business's channel.' This distinguishes it from sibling tools like find_business by focusing on verification of existing SMBs rather than discovery.

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' sections, including a specific alternative (find_business) and a 24-hour verification window. This is exemplary guidance that clearly explains when to invoke the tool versus alternatives.

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