Professor Sausages — Trust & Verification

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

With no annotations provided, the description carries the full burden. It discloses the two-phase call behavior, the 'never a silent all-clear' guarantee, the live OFAC SDN list, and chain segmentation. It stops short of error handling or exact return schema, but gives key behavioral insight.

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 concise sentences with front-loaded purpose. Each sentence adds distinct value: purpose, return behavior, and payment flow plus pricing tool reference. 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 paid tool with a two-phase workflow, the description explains the payment mechanism, data source, segmentation, and return behavior. It doesn't detail the exact verdict structure, but without an output schema, this is acceptable. The pointer to the pricing tool adds completeness.

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

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

Schema already covers all parameters (100%), so baseline is 3. The description adds meaning to x_payment by explaining that omitting it returns payment terms and including it settles the call, which is beyond the schema's 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 with a specific verb ('Screen') and resource ('a crypto address against the full live OFAC SDN list, segmented by chain'). It differentiates from sibling tools by specifying crypto address screening and chain segmentation.

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 describes the two-phase payment workflow (call without x_payment to get terms, then call with x_payment) and points to the pricing tool for a full price list. While it doesn't explicitly name alternative screening tools, the crypto-specific focus and payment instructions provide clear usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently reveals the paid nature of the tool, the x_payment handshake, and the fact that the 'live' view re-reads the registry in real time. It does not mention potential error behavior or rate limits, but this is a notable disclosure effort.

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 dense but efficient, with each sentence contributing distinct value: data content, view specifics, payment flow, and alternative pricing tool. It is well-organized with clear semantic chunks and 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 complex paid tool with multiple views and no output schema, this description is comprehensive. It covers what data is returned for each view, the payment handshake, and the available free alternative. The only minor gap is lack of explicit error scenarios, but the provided information is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, providing baseline of 3. The description adds meaning by explaining the values of 'view' ('dns' returns DNS summary, 'live' re-reads registry) and detailing the x_payment flow. This goes beyond the schema's terse property descriptions.

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

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

The description explicitly states the tool returns an 'RDAP registration card' with detailed domain data and derived risk flags, and clearly distinguishes between registration, DNS, and live views. It differentiates from sibling tools by focusing on domain intelligence and even points to the 'pricing' tool for pricing needs.

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 clear guidance on when to use each view and explains the payment flow: call without x_payment to receive terms, sign, then call again. It also mentions the free 'pricing' tool as an alternative for price discovery. However, it does not explicitly state when not to use this tool versus other sibling tools, but the distinct domain focus makes it implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the paid two-step process (call without x_payment to get terms, sign, then call again), the DNS-over-HTTPS method, and the important limitation that it is not a guaranteed inbox verdict. This is substantive behavioral context beyond the 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 densely packed but efficient: two sentences cover purpose, checks, limitations, and the paid workflow. It is front-loaded with the core deliverability information and has zero wasted words.

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

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

Despite no output schema or annotations, the description covers what is checked, the evidence-based nature, the payment workflow, and a key limitation. It does not describe the exact output structure, but for a tool with this complexity, the provided context is sufficient for an agent to call and interpret results 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% for both parameters, so the baseline is 3. The description adds critical semantics for x_payment by explaining the exact payment flow and the meaning of omitting it, and clarifies email is for one address, which enriches the schema's simple descriptions.

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 what the tool does: deliverability signals for one address, listing specific checks (RFC5322 syntax, MX/SPF/DMARC, disposable/role-account flags). It differentiates from siblings by focusing on single-address email deliverability, not broader domain intelligence or screening.

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 clear context: it is for checking a single address and returns signals with evidence, not a guaranteed verdict. It does not explicitly name alternatives or exclusion criteria, but the 'one address' scope and the specific signal list imply appropriate use cases.

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

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

With no annotations, the description carries the burden. It discloses that it searches local datasets first, then the broader catalog, and returns endpoints with method, URL, price, and call instructions. Also notes the tool is free—useful context not in the 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?

Two sentences with a clear flow and practical examples. Dense but not bloated; every sentence adds value. The examples are numerous but the overall length is appropriate for a discovery tool.

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 no output schema, so the description must explain return value. It fully covers what is returned (matching endpoints with method, URL, price, call instructions), the search order, and pricing. Complete for its purpose.

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% for the single 'task' parameter, but the description enriches semantics by framing it as a plain-language request and giving examples. This goes beyond the schema's basic 'in your own words' 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?

Purpose is explicit: find data sources by describing the need in plain language. The description clearly states it searches datasets then the catalog and returns matching endpoints, distinguishing it from sibling tools that perform specific checks.

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 multiple concrete examples of when to use it (e.g., 'Apple risk factors', 'is this token a honeypot') and explains the search scope. It does not explicitly state when not to use it, but the use case is clear enough.

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

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

No annotations provided, so description carries full burden. It discloses the payment behavior (paid terms flow), what each view does, and the validation algorithm (length + mod-97). Does not mention error/rate limits, but this is substantial for a validation tool.

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

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

Four sentences, each with distinct value: validation method, view behaviors, payment flow, and pricing alternative. No filler, front-loaded with purpose.

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

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

For a 3-param tool with no output schema, the description covers the main operations and the complex paid workflow. It doesn't describe return structure, but that's not essential without an output schema. Sibling context makes selection easy.

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%, baseline 3. Description adds meaning to view enum ('decode' resolves parts, 'format' returns electronic/paper forms) and explains x_payment flow in greater detail than the schema. iban param not elaborated, but schema already says spaces optional.

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

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

States specific operation: 'Validate an IBAN (length + mod-97 check digits)' and describes two distinct views (decode, format). Clearly identifies the resource (IBAN) and differs from sibling validation tools (email_check, phone_check, etc.).

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 clear workflow for paid calls: call without x_payment to get terms, sign, then call again with x_payment. Also points to the free `pricing` tool for all prices. Does not explicitly name alternative IBAN tools, but siblings are clearly different resources.

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?

Given no annotations, the description carries the full burden. It discloses that the operation is 'Pure CPU, no third-party lookup' and fully explains the paid nature and exact terms exchange. It does not cover error conditions or rate limits, but the core behavioral traits are transparent.

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

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

The description is compact and well-structured: first sentence states the core purpose, second explains performance/trade-offs, and the final part details the payment flow. Every sentence earns its place 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?

Despite no output schema, the description lists the key return values (E.164, line type, region, verdict). The complex payment flow is fully explained, and the pointer to the pricing tool covers alternative needs. Minor gaps like error handling are not critical for a validation 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 100%, so baseline is 3. The description adds meaningful context for the x_payment parameter, explaining the exact usage flow (omit to get terms, sign, then provide). This goes beyond the schema's description and clarifies the parameter's role.

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: 'Validate and normalize a phone number' and specifies what it returns (E.164 form, line type, region, verdict). This is specific and distinct from sibling tools like email_check or domain_intel.

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 provides clear context for the two-step payment process ('call without x_payment... then call again with x_payment') and points to the pricing tool as an alternative for price discovery. It does not explicitly mention when not to use this tool, but the context is strong for a paid validation flow.

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

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

With no annotations, the description carries the full transparency burden. It adds value by stating the data is 'read live from the route table' and that the tool itself is 'Free', which are behavioral traits not captured elsewhere. It doesn't mention output format or side effects, but for a read-only pricing list this is sufficient.

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

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

The description is a single, well-structured sentence that front-loads the core purpose ('Every endpoint this server fronts') and packs in pricing details, currency, chain, live source, and cost—all without wasted words.

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

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

Given the absence of an output schema, the description adequately conveys the content (endpoints, prices, summaries) and source (route table). It doesn't specify exact response structure or pagination, but for a zero-parameter pricing list, the description is complete enough for an agent to understand what it will receive.

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

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

The schema has zero parameters, and the rubric sets a baseline of 4 for 0-parameter tools. The description adds no parameter-specific meaning, but none is needed since no parameters exist.

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 providing a live list of all endpoints with their exact per-call USD prices and one-line summaries. It distinguishes itself from the data-lookup sibling tools (e.g., address_screen, email_check) by focusing on pricing information.

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

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

No explicit when-to-use or alternative guidance is given, but the purpose is self-evident: use this tool to look up endpoint prices. The distinction from siblings is implied by the nature of the content (pricing vs. data lookups), but explicit exclusions are absent.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that requests feed a nightly ingestion queue, that filings are typically available in ~24h, that including contact enables follow-up, and that the service is free. This is strong behavioral context, though it doesn't cover potential limitations like whether all requests get fulfilled.

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 exceptionally concise: two sentences that capture the core purpose, give concrete examples, explain the queue behavior and latency, note the optional contact field, and state it's free. Every clause earns its place with no fluff or 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 request tool with 3 parameters and no output schema, the description fully covers what the tool does, when to use it, what to expect in terms of follow-up, and that it's free. It is complete enough for an agent to select and invoke correctly alongside sibling tools.

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 each parameter having a description and example. The tool description adds context about the nature of acceptable requests (pre-2015 filings, uncovered tickers, etc.) but does not add significant meaning beyond what the schema already provides for the parameters themselves, keeping the score at baseline.

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

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

The description uses a specific verb ('ask for data we don't have') and clearly distinguishes this from sibling lookup/screening tools by framing it as a 'suggestion box' for requesting unavailable data. It lists concrete examples (pre-2015 filing, uncovered ticker, unsupported chain) that make the purpose unmistakable.

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

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

The description clearly implies when to use this tool: when data is missing from the existing coverage, as shown by examples and 'data we don't have.' It does not explicitly name alternatives like find_data for existing data, but the phrasing plus sibling list makes the boundary clear enough.

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

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

No annotations provided, so the description carries the burden. It discloses the two-step payment flow, the paid nature, and the types of data returned. It does not mention rate limits or auth details, but covers key behavioral aspects.

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 sentences: purpose, usage, payment. Each sentence adds a distinct layer with no redundancy. The main purpose is front-loaded, and every word 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?

No output schema, yet the description enumerates returned data types (aliases, addresses, programs, identifiers). It fully explains the payment terms flow and references the pricing tool for cost transparency. Sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for x_payment, explaining the sign-and-resubmit process. It reinforces the source of id (screen result) without contradicting the schema.

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

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

The description explicitly states it returns 'the complete OFAC record for one entity number' and enumerates contents (aliases, addresses, sanctions programs, identifiers). It distinguishes from siblings by saying to use it after sanctions_screen returns a candidate.

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 context: 'Use after sanctions_screen returns a candidate.' It also names an alternative for pricing: 'The free `pricing` tool lists every price at once.'

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is paid, requires a two-step x_payment flow, returns match/possible_match/no_match with scored candidates and matching aliases, and guarantees it never gives a 'silent all-clear.' This goes well beyond the schema and gives agents critical 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 three dense sentences with no fluff. Each sentence earns its place: the first defines what it does and returns, the second explains the payment flow, and the third directs to the pricing tool. Perfectly sized for the complexity.

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 explains the return types and candidate details sufficiently. It also covers the payment flow, which is essential for a paid tool, and mentions the pricing alternative. This is complete for an agent to decide when and how 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?

Schema coverage is 100%, so the baseline is 3. The description adds operational meaning for x_payment (the two-step terms-then-pay flow) and reinforces fuzzy matching for name and min_score. This extra context elevates it beyond the schema alone.

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 action ('Fuzzy-screen a name') and specific target ('full OFAC SDN + Consolidated lists'), which distinguishes it from sibling tools like address_screen or vessel_screen. It also specifies the output categories (match / possible_match / no_match), making the purpose unmistakable.

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

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

The description provides explicit payment workflow guidance: call without x_payment to get terms, sign, then call again with x_payment. It also points to the free 'pricing' tool as an alternative for viewing all prices. However, it does not explicitly compare against other screening tools (e.g., sanctions_entity) for when to use name screening over entity screening, though the 'name' focus implies this.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It details the two-step paid call pattern, the data sources (URLhaus snapshot + live heuristics), and the nature of the response ('verdict with the rules that fired'). It does not cover potential limitations or rate limits, but the core behaviors are clearly disclosed.

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: it states the core function in the first sentence, describes the return value in the second, and explains the payment flow in the third. No redundant words, every sentence earns its place, and important information is front-loaded.

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

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

Given the moderate complexity (multi-step payment, standalone heuristic logic) and lack of output schema, the description sufficiently covers the tool's behavior, return value, and payment workflow. It could further clarify the verdict format or edge cases, but overall it provides enough context for an agent to use the tool correctly.

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

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

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including the payment workflow for x_payment. The tool description largely repeats this information, adding no meaningful new semantic value beyond the schema. Baseline 3 is appropriate when schema coverage is high and the description does not compensate with additional context.

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

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

The description clearly states it 'Screen a URL against the URLhaus blocklist snapshot plus deterministic live heuristics' with specific method details (redirect chain, host reputation, lookalike patterns). This distinguishes it from sibling tools like address_screen or domain_intel by focusing on phishing/malicious URL screening.

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 clear usage context for the payment workflow ('call without x_payment to receive terms...') and explicitly names the free `pricing` tool as an alternative for price discovery. However, it does not explicitly explain when to choose this tool over sibling screen tools, though the title and content make the intended use fairly 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool is paid, requires a two-step x402 payment flow, and that the first call returns payment terms rather than data. This is important behavioral context, though it doesn't cover error handling or response format.

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 three sentences, each earning its place: purpose, payment flow, and pricing tool reference. It is concise and front-loaded with the core purpose.

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

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

With no output schema and no annotations, the description should explain return values. It covers payment mechanics and matching modes well, but does not describe the response format, pagination, or behavior when no match is found. It is adequate but has gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates matching criteria (fuzzy name, exact call sign, IMO, flag) and the x_payment flow, but the schema already documents each parameter, including x_payment's detailed explanation. The description adds minimal new parameter-level 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?

The description clearly states the tool screens vessels against OFAC maritime designations using multiple identifiers (fuzzy name, exact call sign, IMO) and flag filtering. This distinguishes it from sibling tools like sanctions_screen or sanctions_entity.

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

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

The description explicitly explains the paid flow: call without x_payment to get terms, sign them, and call again with x_payment. It also points to the `pricing` tool for listing all prices. However, it doesn't explicitly contrast with non-vessel sanctions screens.

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