Verify a Company

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds meaningful operational context beyond that: cost is free with no key required, latency is ~50ms, and the tool is restricted to completed operations. It also discloses that the result includes cost and reason codes, which is useful behavioral information not present in 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 short, front-loaded with the core purpose, and organized into scannable WHEN TO USE/WHEN NOT TO USE/COST/LATENCY sections. Every sentence earns its place with no 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 single-parameter low-complexity tool with rich annotations, the description covers purpose, timing, cost, latency, and high-level return contents. The only notable gap is the explicit origin of operation_id; otherwise the agent has enough guidance to call 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 description coverage is 0%, so the description must compensate for the undocumented operation_id parameter. It implies the ID comes from operations tracked by get_status, but it never explicitly states that operation_id is the ID returned by get_status or how to obtain it. This is a gap for an agent deciding what value to supply.

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

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

The description uses a specific verb ('Retrieve') and a clear resource ('final OutcomeReceipt') scoped to completed operations. It distinguishes itself from get_status by stating the phase of the operation it applies to, leaving no ambiguity about what the tool does.

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 state that the tool should be called only after get_status indicates success/failure/partial and not for pending/executing operations. It names the alternative tool (get_status) directly, making selection unambiguous.

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. The description adds useful behavioral context such as cost, latency, and the operational constraint not to poll more often than every 10 seconds. This goes beyond what the annotations provide 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 compact and well-structured with labeled sections for usage, cost, and latency. Every sentence adds operational value, and the core purpose is front-loaded before the supplementary 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?

For a single-parameter read-only tool with strong annotations, the description covers the essential invocation context: what to pass, why to poll, backoff advice, and cost/latency. It does not specify the exact response shape or possible status values, but no output schema exists and the operation semantics are reasonably inferable. A note distinguishing this from sibling get_outcome would improve completeness, but it is not a critical 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 schema provides only the parameter name and type (string), with 0% description coverage. The tool description clarifies that operation_id identifies an async operation, but does not add format, source, or example details. Since there is only one parameter and its purpose is largely self-evident, 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?

States a precise verb ('Query'), resource ('current state of any in-flight async operation'), and key parameter ('by operation_id'). This clearly identifies what the tool does and distinguishes it from generic or unrelated 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?

Provides explicit WHEN TO USE and WHEN NOT TO USE guidance, including polling vs. webhook delivery and a concrete 10-second rate limit. This is exactly the kind of decision-making context an agent needs to select and invoke the tool correctly.

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 false, and the description adds valuable behavioral context: zero cost, no API key required, ~1200ms latency, 2020-2026 data coverage, and top-award sorting by dollar amount. There is no contradiction with annotations, and the additional details go beyond what structured 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 longer than average but well-structured with headers, examples, and explicit use/not-use guidance. Virtually every section adds decision-relevant value, though the target-demand keyword list and repeated examples could be trimmed without losing critical meaning. Overall, it is appropriately organized and front-loaded.

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

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

Given two simple parameters, no output schema, and rich annotations, the description covers all essential context: data source, return fields, coverage years, cost/latency, limitations, and alternatives. An agent has everything needed to invoke the tool correctly and interpret what comes back.

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%, with both company_name and max_results fully documented including default, min, max, and sorting behavior. The description itself does not add much parameter-level meaning beyond the schema, but example queries reinforce correct usage. Baseline 3 is appropriate because the schema already carries the semantic load.

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

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

The description uses a specific verb and resource: 'Search US federal contract awards by company (recipient) name using the free USASpending.gov public API.' It also clearly states what is returned and differentiates itself from siblings by explicitly excluding sanctions and verification use cases. An agent can immediately understand the tool's unique role.

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 dedicated 'WHEN TO USE' and 'WHEN NOT TO USE' sections, naming specific alternatives like verify_company_record and screen_sanctions. It also gives concrete example user queries that map directly to parameter values. 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?

Major behavioral traits are disclosed beyond annotations: the response may be exact or a min/max range depending on channel/outcome, it 'does not promise an accuracy percentage - check cost_range,' and the cost is free with ~100ms latency. These details inform the agent's expectations and are not visible in the 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 organized into clear sections (summary, examples, when to use, when not to use, cost, latency) with no filler. Every sentence contributes decision-relevant information, and the core purpose is front-loaded in the first sentence.

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 there is no output schema, the description explains what the response will contain (cost, latency, success-probability, exact vs range, cost_range field). It also covers usage constraints, caching, cost, and latency, so an agent has enough information to invoke the tool correctly without needing 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 only describes 'params' and leaves 'operation' undocumented (50% coverage). The description compensates with two concrete call examples showing the shape: preview_cost({"operation": "send_message", "params": {"preferred_channel": "sms"}}). It adds meaningful context for both parameters, though it does not explicitly define 'operation' in prose.

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 and resource: 'Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution.' It clearly differentiates from siblings by being the only tool about cost preview, and it provides concrete example queries that demonstrate the intended use.

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 guidance ('Use before any operation when the agent is operating under a budget constraint and needs to decide whether to proceed') and WHEN NOT TO USE guidance ('Do not use in a hot loop — cache the result for at least 60 seconds') are both present. Although no alternative sibling is named, none of the siblings serve a similar purpose, so this is complete.

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 reveals substantial behavioral detail beyond the annotations: it explains that the tool never fabricates results, reports partial screening via reason_code, discloses which lists actually ran, and returns an Ed25519-signed compliance receipt. This strongly aligns with readOnlyHint and idempotentHint and adds safety-relevant 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 well-structured with clear sections, but it is longer than necessary: four example user queries are largely redundant, and the source-list and UN-exclusion points are repeated several times. Every section contributes value, yet trimming would improve focus.

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

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

Despite having no output schema, the description fully characterizes the response: screening_status priorities, matched semantics, match fields, lists_screened, sources_unavailable, reason_code, and compliance_receipt. It also covers failure behavior and tells the agent exactly what to branch on, so nothing needed for correct invocation is missing.

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 already provides full parameter descriptions (100% coverage), so the baseline is 3. The description adds value with real example user queries mapped to exact parameter values and clarifies that country annotates and ranks results rather than filtering them, which is meaningful semantic nuance.

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 a free sanctions-screening tool with an explicit verb ('screening') and resource ('a name or entity against official sanctions lists'). It further distinguishes itself by naming the exact source lists, excluding the UN list, and differentiating from siblings like get_status or verify_company_record.

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?

Dedicated WHEN TO USE and WHEN NOT TO USE sections specify concrete contexts such as onboarding, payment processing, vendor engagement, and due diligence. It also explicitly excludes KYC/AML, PEP screening, adverse media, and bulk screening, which gives an agent clear 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 substantial behavioral detail beyond the annotations: it runs exactly 6 internal checks, reports a count, does not test individual tools, is free, takes ~200ms, and should not be called more than once per minute. This goes well beyond the readOnly/idempotent/non-destructive hints.

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, then provides concrete usage examples, when-to-use guidance, cost, latency, and rate-limit restrictions. Each section adds practical value without unnecessary 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?

For a parameterless health-check tool with strong annotations and no output schema, the description covers everything an agent needs: what it does, what it does not do, when to use it, rate limits, cost, latency, and an example invocation. Nothing essential is missing.

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 and an empty schema, so there is little for the description to clarify. The description correctly implies the call takes no input by showing 'call self_test({})'. This is the appropriate baseline for a 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?

The description clearly identifies a specific verb and resource: 'Service health probe: runs 6 internal checks and reports how many passed.' It explicitly distinguishes itself by noting it does NOT probe each tool individually, which helps differentiate it from sibling data-lookup 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 gives explicit WHEN TO USE guidance ('agent startup, before high-stakes task sequences, or after unexpected errors') and WHEN NOT TO USE ('Do not call more than once per minute'). It provides an example user query. It does not explicitly compare itself to sibling tools, but the scope is clear enough for 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 mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral depth: it never fabricates results, returns an honest not_found with the queried sources, and reveals cost and latency. This strongly informs an agent about side effects and reliability 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 longer than average but organized into labeled sections (WHEN TO USE, WHEN NOT TO USE, COST, LATENCY) and front-loaded with the core purpose. The example queries are valuable. Minor redundancy exists between the opening 'Free' and the COST line, but overall every section earns its place.

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

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

For a 3-parameter tool with no output schema, the description is complete: it states the data sources, return fields, not_found behavior, usage boundaries, cost, and latency. An agent has enough context to select this tool correctly and interpret the response even 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?

Input schema already covers all three parameters with descriptions, so baseline is 3. The description adds relational meaning: name is required and can be paired with an optional country filter, while LEI enables a direct precise lookup. The example user queries map natural-language utterances to concrete parameter combinations, which exceeds schema-only information.

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?

Opens with a specific verb+resource: 'Free, live lookup of a company official registry record.' It names the data sources (GLEIF, SEC EDGAR), the exact fields returned, and the not_found behavior, so an agent can clearly distinguish it from a generic search or a sanctions screen. The example queries further reinforce the intended scope.

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 scenarios (contract signing, vendor qualification, counterparty validation) and WHEN NOT TO USE exclusions (private companies not in GLEIF/SEC, exhaustive fraud detection). It does not name an alternative sibling tool like screen_sanctions, so it stops short of full alternative routing, but the guidance 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.