Sausage Trust

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

With no annotations, the description carries the full behavioral disclosure. It reveals the 'never a silent all-clear' guarantee and explains the two-step payment handshake (call without x_payment for terms, then call again with x_payment for data). This adds meaningful 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 only three sentences: purpose, output guarantee, and payment flow. It is front-loaded with the core action and every sentence carries essential information without 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?

This is a paid, two-phase API with no output schema. The description covers the two-step payment, the response shape (verdict with evidence), and the pricing alternative. It could elaborate on the verdict structure, but it is adequate for a tool of this complexity.

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 descriptions already cover 100% of parameters, including chain enum, address format, and x_payment flow. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.

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 a crypto address against the full live OFAC SDN list, segmented by chain. This is a specific verb (screen) plus a well-defined resource, and the chain segmentation differentiates it from broader sanctions screening 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 explains the two-phase paid call flow and explicitly points to the free `pricing` tool as an alternative for price lists. However, it does not explicitly say when not to use this tool versus `sanctions_screen` or `sanctions_entity`, so the guidance is context-rich but lacks explicit exclusions.

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 fully discloses behavior: the default registration view, the 'dns' view returning live multi-record DNS summaries, the 'live' view re-reading the registry, and the paid x_payment flow (call without payment to get terms, sign, then call again). This is transparent about payment requirements and operational semantics.

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, front-loaded with the core purpose, followed by view specifics and payment instructions. Every clause adds value, with no repetition or filler. The DNS record list is long but necessary for expected output.

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 and no annotations, the description covers the purpose, all three views, the contents of each view, and the payment workflow. It provides enough return-value context (registration fields, DNS records) and behavioral details to guide an agent without requiring additional documentation.

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 semantic meaning beyond schema: it enumerates the DNS record types returned in the 'dns' view (A/AAAA/CNAME/MX/NS/TXT/SOA/CAA + SPF/DMARC), clarifies that 'live' re-reads the registry, and elaborates the x_payment handshake. This enriches parameter understanding.

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 specific action: returning an RDAP registration card for a domain, and enumerates exact data fields (creation/expiry dates, registrar, statuses, nameservers, DNSSEC) plus derived risk flags. It also distinguishes DNS and live views. This is clearly distinct from sibling tools focused on other entity types, such as email_check 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 states the tool is for domain registration and DNS intel, and even points to the free 'pricing' tool as an alternative for cost listing. However, it does not explicitly exclude overlapping sibling tools like url_screen or find_data, leaving some ambiguity around when to choose this over those.

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. It discloses payment requirement, the DNS-over-HTTPS mechanism, and explicitly warns 'not a guaranteed inbox verdict', which sets expectations about certainty. It does not disclose rate limits or failure modes but provides key behavioral context beyond basic mutation/read 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 three sentences, front-loaded with the core purpose and signals, followed by the payment details. It avoids unnecessary filler and every sentence contributes either to purpose, limitation, or payment flow. The format is readable and scannable.

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

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

The tool has moderate complexity (payment flow, multiple signal categories) and no output schema, so the description needs to explain both input semantics and what the agent will receive. It lists the signal types and the payment terms, which covers most of what a caller needs to know. It lacks explicit output structure (like field names) but is otherwise comprehensive for an AI agent.

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

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

The input schema already provides full descriptions for both email and x_payment, including the payment flow semantics. The description adds no new parameter-specific details beyond what the schema states, so it neither increases nor decreases the baseline. The payment flow is mentioned in both places, but the schema's x_payment description is equally informative.

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 'Deliverability signals for one address' and enumerates specific checks (RFC5322 syntax, MX/SPF/DMARC, disposable/role flags), making it clear this is an email-specific verification tool. It distinguishes from siblings like domain_intel by scoping to a single address. The limitation note further clarifies 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?

The description explains the two-step payment workflow (call without x_payment to get terms, then call again with signed payment), and points to the free pricing tool as an alternative for seeing all prices at once. However, it does not provide explicit guidance on when to choose this tool over related siblings like domain_intel or address_screen, leaving that inference to the agent.

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. It discloses the search order (local first, then Professor Sausages catalog), what is returned (method, URL, price, how to call), and that it is free. It does not mention limitations like result caps or whether the tool executes the underlying request, but it is otherwise 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?

Two sentences, front-loaded with the main action, and every clause earns its place: usage instruction, examples, search scope, output content, and price. There is no fluff or repetition.

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

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

For a simple one-parameter discovery tool with no output schema, the description is complete. It explains the input format, the search behavior, the output contents, and cost, making it fully actionable for an agent deciding whether 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% for the single 'task' parameter, so the baseline is 3. The description adds value beyond the schema by giving additional examples of plain-language queries (e.g., 'is this token a honeypot', 'read this page'), showing the parameter accepts questions and imperative phrasings, not just data requests.

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 discovery/search action ('Searches... returns matching endpoints') with a specific resource (data sources/endpoints). It distinguishes itself from sibling tools by showing it accepts plain-language requests and covers the whole catalog, unlike the specific screening tools listed as siblings.

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 clear usage context: describe what data you need in plain language, and it searches local then global catalogs. Examples like 'is this email deliverable' imply it can route to sibling tools like email_check, but it does not explicitly state when not to use this vs. direct alternatives.

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

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

With no annotations, the description carries the full burden and discloses the paid nature and the two-step payment process, which is critical. It also explains what each view returns (country/bank/account parts vs electronic/paper forms). It omits output format and invalid-IBAN behavior, but the core behaviors are well covered.

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, front-loaded with the main purpose. Each sentence contributes: the validation and views, the payment workflow, and the pointer to the pricing tool. No 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?

The paid flow is complex and thoroughly explained, including the two-step payment and the pricing alternative. The views are described with their outputs. However, there is no indication of what the 'validate' response looks like (e.g., boolean, error details), and no output schema exists to fill that gap. This prevents a perfect score.

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?

Even though schema coverage is 100%, the description adds substantial value beyond the schema. It explains the functional difference between 'decode' and 'format', and details the x_payment lifecycle (omit to get terms, sign, resubmit). This goes well beyond the baseline for full schema coverage.

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

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

The description clearly states the tool validates IBANs using length and mod-97 check digits, and explains the decode and format views. This is a specific verb+resource description that distinguishes it from sibling tools like sanctions screening or phone 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?

It provides explicit payment workflow guidance: call without x_payment to get terms, sign, then call again. It also directs users to the free 'pricing' tool for a complete price list. It does not explicitly compare with sibling tools, but the domain is distinct enough that this is not a significant gap.

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 present, so the description carries full burden. It explicitly says 'Paid:' and explains the two-step payment workflow with x_payment, plus 'Pure CPU, no third-party lookup.' This discloses cost, execution environment, and external dependency behavior clearly.

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/outputs, execution model, and payment workflow. No redundant wording or 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?

Despite no output schema, the description names all output types (E.164, line type, region, verdict). It also explains the payment behavior and the free `pricing` alternative, giving an agent enough context to 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 significant meaning to `x_payment` by explaining the exact workflow (omit for terms, sign, then call again). It also implies the `number` parameter's validated output (E.164 form), but does not detail `region` beyond 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 opens with 'Validate and normalize a phone number,' a specific verb and resource, and lists concrete outputs (E.164 form, line type, region, verdict). This clearly distinguishes it from siblings 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?

The description does not explicitly state when-not-to-use, but it says 'The free `pricing` tool lists every price at once,' directing pricing-related queries to an alternative. The purpose sentence implies when to use the tool, but lacks explicit exclusion of alternative validation 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?

With no annotations, the description carries the full burden. It discloses that data is 'read live from the route table' (read-only, dynamic) and 'Free' (no cost). It could mention output format or rate limits, but for a simple listing tool, this is adequate transparency.

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, efficient sentence followed by 'Free.' It packs endpoint list, price, currency, summary, and live-read behavior with zero wasted words. Every part contributes to understanding the 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?

For a tool with no parameters and no output schema, the description is quite complete. It says 'every endpoint' and explains exactly what is returned (price and summary). It doesn't specify output format or authentication, but those are non-critical for this simple list tool. The sibling context further clarifies its niche.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds value by clarifying what the returned data will contain (prices and summaries), but since there are no params to document, it doesn't need to compensate.

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

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

The description clearly states what the tool does: it returns every endpoint with its exact per-call USD price, currency (x402/USDC on Base), and a one-line summary. It distinguishes itself from sibling data tools by focusing solely on pricing, and the verb 'lists' is implied by 'Every endpoint... with its exact per-call USD price'.

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 strongly implies this is the reference to consult before calling paid endpoints, especially with 'Free' indicating no cost. It doesn't explicitly name alternatives or say 'use before any paid call', but given it's the pricing list, the usage context is clear. No exclusions are needed.

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 full burden. It discloses the asynchronous behavior (nightly queue, ~24h availability) and that it's free. This goes beyond the schema and gives the agent a good sense of expectations, though it doesn't mention any confirmation or feedback mechanism.

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, front-loaded with the core purpose and examples. The second sentence covers behavior, timing, and a parameter use case. Every word earns its place; no 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 simple request tool with no output schema, the description covers purpose, process, timing, and cost. It doesn't explicitly mention how to use the sibling find_data for existing data, but the context is sufficient. A 5 would require an explicit exclusion, but the tool is well-scoped.

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 baseline is 3. The description adds value by explaining that the optional contact is for follow-up ('Include contact if you want to hear back'), which nuances the contact parameter beyond the schema. It also re-emphasizes the 'description' field with examples, though these are already in 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 clearly states the tool's purpose: 'ask for data we don't have' with specific examples (pre-2015 filing, uncovered ticker, unsupported chain). This distinguishes it from sibling tools like find_data, which presumably retrieves existing data, making the intent unambiguous.

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

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

It provides clear context for when to use the tool: when data is missing ('data we don't have') and describes the process (nightly ingestion queue, ~24h turnaround). However, it does not explicitly name alternatives or state when not to use it, which would make it a 5.

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 exist, so the description carries the burden. It discloses the critical paid nature and the exact workflow: call without x_payment to get terms, sign, then call again with x_payment. This is significant behavioral context beyond the schema, though it doesn't mention failure modes or response structure.

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, each serving a purpose: function, usage context, and payment flow. Information is front-loaded and there is no redundancy or 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?

The description adequately covers purpose, usage context, payment mechanism, and output contents (aliases, addresses, programs, identifiers). Since no output schema exists, this listing helps set expectations, though it omits error handling details which are not critical for this 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%: both `id` and `x_payment` already have detailed descriptions. The tool description adds no new parameter-specific semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns the complete OFAC record for one entity, including aliases, addresses, programs, and extracted identifiers. It distinguishes itself from sanctions_screen by focusing on a single candidate entity, but lacks an explicit verb like 'Gets' or 'Fetches', instead using a declarative noun phrase.

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?

Explicitly instructs to 'Use after sanctions_screen returns a candidate', and explains the two-step payment flow. It also points to the free `pricing` tool as an alternative for listing all prices at once, giving clear when-to-use and 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 key behavioral traits: it returns scored candidates with aliases and never gives a silent all-clear, and it explains the two-step payment process. Since no annotations are provided, the description carries the full burden and does so comprehensively.

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, front-loaded with the core function, then returns behavior and payment workflow. No filler 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?

Given the absence of annotations and output schema, the description provides essential context: result types, payment terms, and a pointer to pricing. The schema covers parameter details, so the description is adequately complete for the tool's complexity.

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?

All six parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds context about the payment flow for x_payment and the result types, but does not add significant new details 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?

Clearly states the tool's function with a specific verb ('fuzzy-screen') and resource ('name against OFAC SDN + Consolidated lists'), and differentiates from sibling tools like address_screen and email_check by focusing on name screening. Mentioning the output classification (match/possible_match/no_match) further clarifies its purpose.

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

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

Provides clear context for when to use this tool—when you need to screen a name against OFAC lists. It also gives explicit guidance on the payment workflow and points to the free pricing tool as an alternative for price discovery. However, it does not explicitly exclude other tools or list alternatives like sanctions_entity.

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 and discloses the core behavior: blocklist plus live heuristics (redirect chain, host reputation, lookalike patterns), the return of a verdict with rules that fired, and the payment mechanism. It lacks details on rate limits or edge-case behavior, but it is substantial for a screening 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?

The description is two sentences with no fluff. The first sentence packs purpose, method, and return value; the second focuses on payment. It is slightly dense but appropriately sized for the tool's 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?

Given the tool has 3 params and no output schema, the description covers the return value ('verdict with the rules that fired') and the payment workflow, which are the critical contextual gaps. It does not discuss error handling or edge cases, but for this level of complexity, it is sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant meaning to the x_payment parameter by explaining the two-step payment flow (omit to receive terms, sign, call again with x_payment). It does not add extra semantics for 'url' or 'follow', but the x_payment context pushes this above baseline.

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

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

The description clearly states the tool's function with a specific verb ('Screen'), a specific resource ('a URL'), and a specific method ('against the URLhaus blocklist snapshot plus deterministic live heuristics'). It also distinguishes this tool from siblings 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 explicit usage context, including the payment workflow (call without x_payment to get terms, sign, then call again with x_payment) and references the pricing tool as an alternative for price information. However, it does not explicitly exclude sibling tools for other intelligence types, so it falls short of a 5.

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 full behavioral burden. It reveals the paid nature, the two-step payment handshake, and the necessity to settle before receiving data. It does not describe output format or error cases, but the core transactional behavior is 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?

Three sentences, each with a distinct role: purpose, payment workflow, and pricing alternative. No redundant wording; the description is front-loaded with the core action 'Screen vessels'.

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

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

Given the tool's complexity (paid API with a payment handshake, multiple search parameters) and lack of output schema, the description provides a complete invocation path: how to query, how to handle payment terms, and where to find pricing. It does not explain the result payload, but that can be inferred from the screening 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?

Schema covers all 6 parameters with descriptions and examples (100% coverage), but the description adds semantic meaning: it clarifies fuzzy name matching, exact call sign, and IMO number, and explains that x_payment is for the payment handshake (omit first to get terms, include to settle). This enriches the schema 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?

Description clearly states the tool screens vessels against OFAC maritime designations, listing specific search criteria (fuzzy name, exact call sign, IMO) and flag filtering. This distinguishes it from sibling tools like sanctions_entity 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?

Provides explicit payment flow instructions: call without x_payment to receive terms, then call again with x_payment. Also points to the free pricing tool as an alternative for price lists. Does not explicitly contrast with sanctions_screen or entity tools, but the domain context implies vessel-specific usage.

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