Flipvo: licenses, entities, NPI, OFAC and OIG screens, carriers, OSHA, drive times

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint=false), and the description adds genuinely new behavioral context: cost ($0.02 per call), the payment mechanisms (x402/USDC on Base via _meta, MPP on the HTTP URL), and that ranking is by real road drive time rather than straight-line distance.

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?

Compact and front-loaded with the pricing/payment constraint, then the functional summary. Payment detail consumes a large share of the text, but every sentence carries actionable 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?

With an output schema present, return values need not be described. The description covers purpose, cost, payment path, and ranking basis adequately; only the disambiguation hint (`near`) is left entirely to the 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 75%, so the schema already carries most parameter meaning (k, near, airport_size all documented there). The description reinforces the k cap ('Up to 5'), the place input, and the scheduled-service filter but adds little syntax or format detail beyond the schema.

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

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

States a specific verb+resource: returns up to 5 airports with scheduled service nearest a named place, ranked by real road drive time, with IATA codes. This clearly separates it from generic siblings like drive_time or drive_matrix, though it never explicitly names an alternative.

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?

Usage is implied by 'nearest a named place' and the airport-size constraint, and it discloses the paid-access requirement. However, it gives no explicit when-to-use/when-not guidance or routing to a sibling 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?

Despite annotations already declaring the read-only/open-world profile, the description adds substantial behavior beyond them: per-call pricing, the x402/MPP payment channel, that an empty result is still a paid 200, the 10-carrier cap, and data provenance (Motus vs legacy frozen 2026-05-14). This is exactly the kind of non-obvious cost and result semantics an agent needs before invoking.

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?

A single densely-packed paragraph where every clause carries information, with payment terms front-loaded (arguably an odd lead, but high-value). It is efficient, though the long run-on return-field list pushes toward density rather than crisp structure.

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?

An output schema exists, so the description needn't explain returns, yet it still enumerates result fields (status, OOS, authority, insurance, fleet size) somewhat redundantly. Combined with cost and caveat disclosure, the definition is essentially complete for calling, with minor overlap against structured output.

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 67%, and the description clarifies identifier formats (USDOT number, MC/MX/FF docket, exact company name with no partial match) and that identity resolution is FMCSA-sourced. It adds real meaning over the schema, though it does not restate the mutual-exclusivity constraint ('exactly one of') that lives in the schema text.

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+resource (US motor carrier lookup) and enumerates the exact identifiers accepted (USDOT, MC/MX/FF docket, exact company name) via FMCSA. It is clearly distinguishable from sibling lookups like entity_lookup, license_search, and nonprofit_verify, which target different entity types.

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?

Usage context is implied ('Not a determination: verify with FMCSA before dispatch') but the description never names an alternative tool or states when another sibling should be used instead. The 10-carrier cap and empty-200 behavior hint at intended scope, but there is no explicit when-to-use/when-not guidance against 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 discloses pricing, payment mechanism via _meta["x402/payment"], the HTTP endpoint, and the 100-element limit, all of which go beyond the annotations. Annotations already declare readOnly and openWorld hints, and there is no contradiction; the description adds meaningful operational 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?

Two sentences with no filler, and each sentence adds distinct information: payment mechanics and core capability. However, the payment details are front-loaded ahead of the tool's actual purpose, and the protocol jargon like 'MPP (tempo)' is dense and unexplained.

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 output schema covers return values and annotations cover the safety profile, so those gaps are acceptable. What remains missing is parameter formatting guidance, clarification of the near parameter, and explicit usage differentiation from drive_time. This is workable for a prepared agent but not fully self-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 description coverage is 0%, so the description needed to explain origins, destinations, and near, but it only indirectly references origins and destinations and never explains their expected format. The combined 100-element cap is useful, but near is completely undocumented and address/coordinate semantics are absent.

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 a drive-time matrix computation over origins and destinations, with an explicit 100-element cap. The contrast with the sibling drive_time tool makes clear this is the multi-pair matrix variant, though it lacks an explicit verb like 'compute' or 'calculate'.

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?

Usage is implied: a matrix for up to 100 origin-destination elements. However, the description never explicitly says when to choose this over drive_time or mentions any exclusions or alternative routing. An agent must infer the distinction from the tool names and the word 'matrix'.

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 openWorldHint=true, covering the read-only nature and open-world assumption. The description adds the critical cost and payment requirement ($0.01 per call via x402) and the MPP endpoint, which are not in annotations. However, it does not disclose response format, rate limits, or error behavior. Given the annotations carry the safety profile, the description adds some value but not extensive behavioral 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 relatively concise, though it mixes payment details with the core purpose. The first sentence states the purpose, then the payment info follows. It is not overly verbose, but the payment info could be considered secondary. The structure is acceptable, though the purpose could be front-loaded more clearly.

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 an output schema (though not shown), so return format may be covered there. However, the description omits details like the difference from drive_matrix, any prerequisites (e.g., valid place names), and how errors are handled. The payment requirement is covered, but other operational context is lacking. For a tool with moderate complexity and a sibling tool that is clearly related, more guidance is 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?

Schema description coverage is only 33%, with only the 'near' parameter having a description. The description adds minimal semantics: it says 'two named places' but does not explain that origin and destination are place names or how to format them. It doesn't clarify the 'near' parameter beyond what the schema provides. With low coverage, the description should compensate but does not, leaving the agent uncertain about parameter usage.

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 core function: 'Driving time/distance between two named places.' It names the resource (driving time/distance) and the operation (compute between origin and destination). However, it does not explicitly differentiate from the sibling drive_matrix, which likely computes a matrix of times/destinations, so the agent might not immediately know when to choose this over the matrix version.

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 no guidance on when to use this tool versus alternatives like drive_matrix. It only mentions the payment method, not the scenarios where a single route query is preferred over a matrix. There is no mention of limitations, prerequisites, or typical use cases. An agent would have to infer usage from the name and schema.

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, openWorldHint, and idempotentHint=false; the description goes further by disclosing the $0.01 price, the two payment paths (x402 USDC on Base via _meta, MPP on the HTTP URL), the data-coverage boundaries, and notably that an empty result is still a paid 200. It does not discuss auth beyond payment or latency/rate limits, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with essentially no filler, though payment mechanics lead while the actual resource description is buried mid-paragraph. Front-loading the operation before the billing detail would read better, but nothing is wasted.

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?

An output schema exists, so return-shape explanation is unnecessary. Given a paid, open-world, non-idempotent lookup, the description covers cost, payment channel, geographic coverage, result limits, field-level inclusions/exclusions, and the charged-empty-result edge case - everything an agent needs before spending money on the call.

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 carry parameter meaning. It does clarify that identification is by entity number OR an exact name (the exactness requirement is absent from the schema) and enumerates the valid states, but it adds nothing about format for entity_number beyond the schema example, and its 'up to 10 entities' claim does not map cleanly onto the single-valued name/entity_number properties.

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 names a specific verb+resource: retrieve a state business-registry record (status, formation, registered agent) by entity number or exact name, and explicitly scopes out officers and street lines. That is enough for an agent to separate it from license_verify or carrier_lookup, but it never names a sibling or states how it differs from them, so it stops short of a 5.

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?

It gives real selection constraints - only five served states (CO, CT, FL, NY, OR), up to 10 entities, and either an entity number or an exact name - which implies when the tool is usable. However it offers no explicit when-to-use guidance against the many sibling verification tools (carrier_lookup, license_search, nonprofit_verify), so routing is left 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 cover only readOnly/openWorld/idempotent hints, so the description carries the rest: per-call price ($0.01), payment mechanism (x402 USDC on Base via _meta, MPP on the HTTP URL), and the non-obvious billing behavior that an empty candidate set is still a paid 200. It also discloses the outputs and the limits of the result's authority.

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?

Very compressed and every clause carries information, but it opens with pricing rather than the purpose, so the core 'what it does' arrives in sentence two. Structure is dense yet mostly earn-your-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?

An output schema exists, so return fields need not be explained, yet the description still names the match payload (name score, reasons, NPI, state, specialty, exclusion type, date). Combined with billing, payment, and confirmation caveats, nothing an agent needs to invoke this correctly 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?

Schema description coverage is 83%, so the schema already documents npi, name, lists, state and min_score. The description adds only that NPI is acceptable input and that state merely re-ranks; limit and min_score are not elaborated, so this sits at the baseline for high-coverage schemas.

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: screen a person/business name or NPI against the HHS-OIG exclusion list (LEIE, Medicare and Medicaid). The named dataset and the 'potential matches only' scope make it immediately distinguishable from sibling tools such as sanctions_screen.

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?

Gives explicit when-not conditions ('Not for employment or credit decisions', 'Not a determination: confirm a match on the OIG online search with the SSN or EIN') and routes agents to a free companion endpoint for list dates and code meanings. It stops short of naming sibling screening tools (e.g. sanctions_screen) as alternatives for other datasets.

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?

Goes well beyond the readOnly/openWorld annotations: pricing ($0.01 per call), the x402 USDC-on-Base payment channel and MPP HTTP endpoint, a 10-record cap, the non-obvious 'empty organizations is a paid 200' behavior, and an explicit disclaimer that no legal conclusion is computed.

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?

Dense but every clause earns its place, with no filler. Slightly imperfect front-loading: pricing and payment mechanics precede the actual purpose statement, so the agent parses cost before function.

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?

An output schema exists, so return values need no explanation. The description covers cost, payment rails, record limits, the empty-result edge case, and the legal disclaimer — everything needed to call and interpret this paid, open-world 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?

Schema coverage is 67% and already documents EIN stripping, exact-name matching, and the state limiter. The description reinforces 'exact organization name' and the EIN/name exclusivity but adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource: 'IRS nonprofit status by EIN or exact organization name,' and enumerates the returned data (BMF exemption subsection, deductibility/foundation codes, Pub 78 listing, automatic revocations). This clearly separates it from siblings like entity_lookup and license_verify.

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?

Explains the two input modes (EIN or exact organization name) and that a name search can be limited by state, giving the agent clear context for invoking it. It does not, however, name sibling alternatives or state when a different tool is preferable.

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?

Goes well beyond the annotations by disclosing cost ($0.01 per call), the payment rails (x402 USDC on Base via _meta["x402/payment"], MPP/tempo on the HTTP URL /v1/npi/verify), the batch ceiling (1-10 NPIs), and the upstream data sources. An agent knows the price, how to pay, and what it is actually reporting before calling.

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?

Front-loads the cost and payment terms, which is the most decision-relevant fact for a paid endpoint, then packs scope and disclaimers tightly. The final sentence runs long with semicolon-chained clauses, but each clause (pricing, payment, coverage, disclaimer) 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?

Covers pricing, payment mechanics, batch limits, returned fields and the liability disclaimer; an output schema exists so return structure need not be restated. The one unresolved gap is how it relates to the exclusions_screen sibling given it also surfaces LEIE exclusions, which leaves a routing ambiguity for the 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?

Schema coverage is 100% and the schema already documents NPIs as 1-10 ten-digit values with valid check digits and no duplicates. The description's '1 to 10 NPIs' clause adds no information beyond the schema, so the baseline 3 applies.

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?

Names a specific verb+resource (npi_verify) and then enumerates exactly what is returned: CMS NPPES status (active/deactivated with dates), provider/org name, practice city/state/ZIP and taxonomies, plus any HHS-OIG LEIE exclusion. An agent can distinguish this from license_verify, exclusions_screen and entity_lookup without opening the schema.

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?

States clear negative scope ('not a credential check and not a determination about the provider') and a hard input bound (1 to 10 NPIs), which tells the agent when this tool is inappropriate. However, it never names a sibling or a condition for choosing it over exclusions_screen, whose screening role overlaps with the LEIE portion here.

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 cover read-only and open-world behavior, but the description adds genuinely load-bearing details beyond them: cost ($0.02 per call), the payment mechanism (x402 USDC on Base via _meta, MPP on the HTTP URL), the fact that an empty result is still billed as a paid 200, name-based matching, and an explicit non-endorsement disclaimer. The one notable omission is that idempotentHint=false is never explained (e.g., repeated paid calls).

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?

All content is substantive, but it is delivered as one long run-on sentence led by billing mechanics, so the tool's actual purpose is buried mid-string and the disclaimer trails at the end. Dense but poorly front-loaded and hard to scan.

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?

An output schema exists, so return values need no explanation. Given that, the description covers everything an agent needs before calling: cost, payment path, data provenance, matching semantics, empty-result behavior, and legal caveats. Nothing material 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?

Schema description coverage is 100%, so the schema already documents employer, state, city, zip, limit and min_score in detail. The description only echoes the matching model ('matched by name', 'city and zip only narrow') and adds no format, matching-tolerance or score-threshold guidance beyond what the schema provides, so the baseline 3 applies.

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: 'Returns the OSHA inspections, violations and penalties on file for an employer in a state.' It also pins the data source (US Department of Labor inspection and violation files) and the output shape (establishments with a penalty roll-up), which cleanly separates it from sibling screening tools like sanctions_screen or exclusions_screen.

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?

Usage context is implied rather than stated: an agent can infer this is the OSHA/regulatory-labor lookup, and the description warns that an employer with no inspections yields an empty paid 200. However, it never names an alternative tool or an explicit when-not-to-use condition, so routing between this and the other screening tools is left 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 and openWorldHint, so the read-only safety profile is established. The description adds valuable behavioral context beyond the schema: the exact per-call cost, the required payment via x402 USDC on Base, the _meta field where payment must be supplied, and confirmation that it is the cheapest paid call.

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 extremely concise at two sentences and contains no filler. It packs cost, payment routing, and purpose into a compact form that an agent can parse quickly.

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 tool with an output schema and clear annotations, the description covers the essential invocation details: payment amount, payment mechanism, where to provide payment, and what the call validates. It could be slightly clearer about what 'pipe' refers to, but nothing critical is missing for an agent to invoke it.

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 schema description coverage is 100%, so the schema has no gaps. The description still adds context by explaining that payment is passed in _meta and that no regular inputs are needed, which is helpful for an agent deciding how to invoke it.

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 tool as a low-cost paid call that 'proves wallet, 402 and receipt work', giving agents a concrete sense of what it does: verify the x402 payment path. It is not a fully explicit verb+resource statement like 'tests payment connectivity', but it is specific enough to separate it from the unrelated sibling tools such as drive_matrix and license_verify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when you need to verify that wallet, 402 payment, and receipts work at the lowest cost. However, it does not explicitly state when not to use it, mention alternatives, or explain how this relates to the sibling tools.

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

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

Annotations only cover read-only/open-world/idempotency; the description adds substantial behavior: $0.01 per call with x402 (USDC on Base) and MPP payment channels, fuzzy matching that folds accents and accepts any script, and the critical caveat that an empty candidate list is a paid 200 that 'certifies nothing'. That is exactly the kind of non-obvious consequence an agent cannot get from 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?

Front-loaded with the billing/payment mechanics an agent must know before calling, then the screening semantics, then the disclaimer. Dense and mostly waste-free, though the payment-channel detail is verbose enough to slightly crowd the functional 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?

An output schema exists, so return values need not be enumerated, yet the description still names the match fields (list, programs, name score, reasons). Combined with pricing, payment mechanism, matching behavior, and the explicit non-determination caveat, nothing an agent needs to call this correctly 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?

Schema coverage is 83%, so the schema already documents dob, type, country and min_score. The description still adds meaning by framing type/dob/country as re-rank inputs only ('only add reasons and re-rank') and noting any-script/any-accent folding, though it never mentions limit or min_score defaults.

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 ('Screen a name against the US OFAC SDN and Consolidated lists') and names the exact fields of the returned matches. It also scopes itself against sibling screening services with 'Not UN, EU or UK', so an agent can distinguish it without opening any schema.

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?

It gives clear usage context — screening a party name, with optional type/dob/country only re-ranking — and an explicit scope exclusion ('Not UN, EU or UK'). What is missing is a positive directive on when to prefer this over siblings like entity_lookup or nonprofit_verify, but the screening context is unambiguous.

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