Polyform

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it is an external paid API call, requires an x402 payment, requires no API key, and returns a simple {reply} object. It also mentions the model family (Llama on Workers AI). The description does not mention possible failure modes, latency, or rate limits, but the provided cost and payment details go well beyond the annotations.

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

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

The description is extremely dense yet compact: it covers purpose, request format, response shape, auth model, and pricing in two sentences. The most important fact (inference gateway / LLM completion) is front-loaded, followed by the exact message structure and then the cost/payment details. There is no filler, and every clause carries useful signal.

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 tool with no output schema, the description is nearly complete. It gives the request format, the response field name, the cost, and the simplified auth model. It lacks only marginal details like error behavior or what happens if a payment fails, and it assumes some familiarity with 'x402.' Still, it provides everything needed to select and invoke the tool correctly in the vast majority of cases.

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 fully documents the single required parameter with 'OpenAI-style messages array,' so the schema-description coverage is 100%, giving a baseline of 3. The description adds concrete semantics by showing the exact array element shape ({role, content}) and the response contract ({reply}). This helps an agent construct valid messages without opening any external documentation, elevating the score above baseline.

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

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

The description opens by identifying the tool as an 'Inference gateway (Llama on Workers AI)' and as a 'Pay-per-call LLM completion.' It specifies the exact resource, the HTTP-style operation (POST with OpenAI-style messages), and the return shape ({reply}). This is a specific verb+resource statement that clearly distinguishes it from the sibling lookup and analysis tools, none of which offer general-purpose chat completion.

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: it is a pay-per-call LLM completion endpoint that requires no account or API key, with a fixed price of $0.01 USDC via x402. This implies the tool is appropriate for one-off or low-cost inference needs without authentication setup, and the payment detail signals cost sensitivity. However, it does not explicitly describe when not to use it or name alternatives (e.g., text_summarize for offline summarization), so it stops short of a full when/when-not guide.

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 destructiveHint=false, so the description only needs to add behavioral context beyond safety. It does so by disclosing that this is a single paid call ($0.50 USDC via x402) and by specifying the exact decision and risk-score output the agent should expect.

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 one dense sentence that front-loads the tool's identity ('Onboarding decision (bundle)') and immediately states the output, data sources, and cost. Every clause earns its place; there is no filler or redundant restatement of the name.

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, the description compensates well by spelling out the return categories (APPROVE/REVIEW/REJECT) and the risk-score range. It also covers pricing and the payment mechanism, which are critical for agent invocation. It could mention score interpretation or thresholds, but that is not essential for selecting and calling the 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 description coverage is 100%, so the schema already documents both parameters. The description adds no meaning beyond what the schema provides: 'business or counterparty name to screen' and 'business domain (optional)' are already in the input schema. 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 identifies the tool as an onboarding decision bundle: one call returning APPROVE/REVIEW/REJECT plus a 0-100 risk score. It names the fused data sources (KYB, OFAC/CSL sanctions, adverse US regulatory actions), which distinguishes it from sibling tools like business_vet or legal_sanctions_screen that cover only part of this 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 implies when to use the tool — when a consolidated onboarding decision is needed rather than separate vetting or sanctions checks — but it never explicitly says 'use this instead of X' or gives exclusion criteria. The 'bundle' framing is useful context, but routing guidance 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=true and destructiveHint=false, and the description adds meaningful behavioral context: it is a paid premium call at $0.25 USDC, returns JSON, fuses sanctions and domain-due-diligence signals into a risk verdict with flags, and names the underlying data areas (registration age, email posture, hosting-IP reputation). No contradictions with annotations.

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

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

The description is one dense, front-loaded sentence that covers purpose, inputs, output, and price without filler. Every clause adds value, and the 'bundle' concept is placed at the beginning so an agent immediately understands the tool's role.

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 only two optional-looking parameters, the description does enough by stating the input rule (name and/or domain), output format (JSON risk verdict with flags), and cost. It could be slightly more explicit that at least one of name or domain must be provided, but an agent can still 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 description coverage is 100%, so the baseline is 3. The description only restates 'Name and/or domain' and adds a minor clarification that either may be used, but it does not add new constraints, formats, or behavior beyond what the schema already documents.

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 a combined KYB/business vet call, names the specific components (OFAC/Consolidated sanctions screen and domain due-diligence), and states the output: an overall risk verdict with flags. The 'bundle' framing and mention of both sanctions and domain checks differentiate it from single-purpose siblings like legal_sanctions_screen or domain_due_diligence.

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 states when to use it: vet a business counterparty before onboarding, and 'one premium call' signals it is meant as a bundled alternative to separate lookups. It does not explicitly name sibling tools or provide when-not-to-use guidance, but the context is clear enough for selection.

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

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

Annotations already cover read-only and non-destructive behavior; the description adds useful behavioral context: source is a public RPC, response is JSON, and each call costs $0.003 USDC via x402. This goes beyond the structured annotations without contradicting them.

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

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

Four short fragments, each carrying distinct information: function, network, asset scope, data source, output format, and price. It is front-loaded with the core purpose and contains no filler 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 one-required-parameter read-only tool, the description is complete: it states what is returned, the network, the source, and the pricing. Without an output schema, the JSON note plus the balance composition is sufficient for an agent to invoke and interpret the 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% and the schema says '0x wallet address', so the baseline is 3. The description adds meaning by specifying that any address on Base mainnet is valid and that the parameter is the wallet whose ETH/USDC balance is returned.

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 Native ETH + USDC balance for a given address on Base mainnet. It lacks an explicit action verb, but 'balance for any address' plus the network specificity is unambiguous. The Base/ETH/USDC scope distinguishes it from crypto_gas, crypto_protocol, and crypto_token_report.

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 it: any time a wallet balance on Base is needed. It does not explicitly name sibling alternatives or state conditions for choosing another crypto tool, so the when/when-not guidance 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 mark this as read-only and non-destructive. The description adds meaningful behavior beyond the annotations: it discloses the data source (public RPC), response format (JSON), and the cost in USDC via x402. This is useful operational context for an agent.

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 front-loaded, packing the core purpose, supported chains, units, source, response format, and pricing into a short text with no wasted words. Every sentence contributes 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?

For a simple one-optional-parameter read-only tool with no output schema, the description is quite complete: it states chains, units, source, response format, and pricing. The only minor gap is that it does not detail the exact JSON return shape beyond mentioning gwei/wei and JSON.

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 fully documents the chain parameter with its allowed values and default. The description restates the supported chains but does not add substantial new meaning beyond what the schema provides, so the baseline score of 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?

The description states a specific verb/resource: it provides the current EVM gas price for Base or Ethereum mainnet. It also specifies units (gwei and wei), making the tool's purpose unambiguous and distinct from sibling tools like crypto_balance or crypto_token_report.

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 indicates the tool is for retrieving current gas prices on Base or Ethereum, giving an agent enough context to select it. It does not explicitly name alternative tools or state when not to use it, but the purpose is specific enough that exclusion is largely unnecessary.

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 destructiveHint=false, and the description adds useful context beyond that: the data source (DefiLlama), output format (JSON), and a monetary cost for the call ($0.03 USDC via x402). It does not contradict annotations and gives the agent practical behavioral expectations about cost and response type.

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 purpose and then lists the returned data fields. It also packs in the source, format, and pricing without unnecessary wording. Every clause earns its place.

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

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

For a simple single-parameter tool with no output schema, the description covers the essential input (slug), the full set of return values, the data origin, the output format, and the cost. Enough information is present for an agent to select and invoke the tool correctly without ambiguity.

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 already fully documents the single parameter 'slug' with examples (aave, uniswap, lido), and the description reinforces that the slug is a DeFi protocol slug. Since schema coverage is 100%, the description adds marginal semantic value beyond the schema, staying within the 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 states a specific operation: retrieving a DeFi protocol brief by slug for one protocol, and enumerates the returned fields (TVL, category, chains with per-chain TVL, audit status, one-line description). It clearly distinguishes this tool from crypto-related siblings like crypto_balance or crypto_token_report by focusing on protocol-level metrics from DefiLlama.

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 context for when to use this tool: when you need a DeFi protocol-level overview in a single call using a protocol slug. It does not explicitly mention alternatives or exclusions, but the scope is specific enough that an agent can infer it is not for wallet balances, gas fees, or individual token reports.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: it returns JSON, supports Base and Ethereum, and costs $0.10 USDC via x402. This goes beyond the annotations without contradicting them.

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

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

The description is a single dense sentence that front-loads the core purpose, then lists key outputs, output format, and pricing. Every clause adds useful information, with 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?

The description covers the invocation context, supported chains, expected outputs, output format, and cost. There is no output schema, so the high-level output list is sufficient. Minor gaps like the exact risk-verdict scale are not critical for calling 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 description coverage is 100%, so the schema already explains 'address' and 'chain' fully. The description mentions Base and Ethereum and token contract address, but these add little beyond the existing schema descriptions. Per the baseline for high coverage, a 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 opens with a clear verb ('vet') and a specific resource ('an ERC-20 token on Base or Ethereum'), then enumerates the concrete outputs: live USD price, holder count, and security signals fused into a risk verdict. This distinguishes it from sibling tools like crypto_balance or crypto_gas, which address different 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 usage context: 'One call to vet an ERC-20 token' signals exactly when to invoke this tool. It does not explicitly name alternatives or state when not to use it, but the context is specific enough that an agent can select it correctly for token due-diligence tasks.

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 destructiveHint=false, and the description's 'Resolve' wording is consistent with those. The description adds useful behavioral context beyond the annotations: the DNS-over-HTTPS mechanism, the JSON response format, and the $0.002 cost per call via x402. It does not mention rate limits or error behavior, but the annotations reduce the burden.

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 definition is a single front-loaded sentence that states the action first, then enumerates record types, transport, output format, and price. Every clause carries distinct information with no redundant or filler wording.

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 read-only two-parameter tool, the description covers purpose, transport, supported types, and cost, making it workable. However, because there is no output schema, it does not specify the JSON response structure, and it also omits error behavior and rate limits. These gaps prevent a higher 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?

Schema description coverage is 100%, so both `name` and `type` are already documented in the input schema. The description repeats the supported record types but adds no additional syntax, formatting, or edge-case guidance for the parameters. With high schema coverage, 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 opens with 'DNS record lookup' and elaborates with a specific verb ('Resolve'), the resource ('any DNS record type for a hostname'), and a concrete list of supported record types. It also names the transport ('DNS-over-HTTPS'), making the tool's function unambiguous and distinct from sibling tools like 'domain' or 'ip'.

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 makes it evident that the tool is for retrieving DNS records, so an agent can infer when to use it. However, it provides no explicit guidance about when to prefer this tool over alternatives such as 'domain', 'ip', or 'url_check', and it gives no exclusions. This is implied usage rather than explicit routing.

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 destructiveHint=false, so the safety profile is covered. The description adds non-obvious context beyond annotations: the data source (registry RDAP), output format (JSON), and the explicit price ($0.005 USDC via x402), which is important for agent decisions. No contradiction.

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

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

Two dense sentences plus compact fragments deliver the core purpose, returned fields, source, format, and price with no filler. Information is front-loaded and every clause adds value.

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

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

For a single-parameter lookup with no output schema, the description lists the key returned fields and the JSON format, plus cost and source, making selection and invocation straightforward. Annotations cover the safety profile, so nothing essential is missing.

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

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

The input schema already documents the single parameter with an example (domain name, e.g. example.com) and has 100% schema description coverage. The description adds nothing about parameter format, normalization, or edge cases, so the baseline of 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?

Description clearly identifies the tool as returning RDAP-based registration intelligence for a domain, and enumerates concrete fields: creation/expiry dates, age, registrar, statuses, nameservers. This distinguishes it from siblings like domain_brand_protection and domain_due_diligence because it focuses on raw registry registration data.

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 usage context: it's for registration data for any domain via RDAP, and the listed fields imply the intended scenario. However, it does not explicitly name alternatives or state when not to use it, so sibling differentiation 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?

Given readOnlyHint and destructiveHint already cover safety, the description adds substantial operational behavior: it generates candidate domains, checks DNS liveness, detects mail-configured domains, and returns a threat verdict. It also discloses the JSON output format and the $0.15 price, which is useful non-obvious 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 a compact, front-loaded block that moves from purpose to process to audience/output/pricing. The opening phrase repeats the title, but the rest of the text is dense and every clause adds information; no significant 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?

With just one required parameter, no output schema, and clear annotations, this description supplies the essential call context: what the tool returns (JSON with threat verdict), what behaviors occur, who should use it, and cost. An agent has enough information to decide to call and to interpret the response at a high level.

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%, and the schema already documents domain as the brand domain and tlds as an optional comma-separated extra list with an example. The description only restates the concept of alternate TLDs and does not add new parameter-level meaning, so the baseline of 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?

The description names a specific action—scanning for typosquat/look-alike domains impersonating a brand—and details the process (misspellings, swaps, homoglyphs, TLDs, DNS checks, mail flags, threat verdict). This is clearly distinguishable from siblings such as dns_lookup or domain_due_diligence because it scopes to brand-protection typosquatting.

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 explicitly says this is for brand and security teams and frames the tool as a one-call bundle, making the primary use case obvious. It does not name alternative tools or state when not to use it, so it stops short of full when/when-not guidance.

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

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

Annotations already indicate read-only, non-destructive behavior, so the description adds value by specifying the audit scope, the PASS/WEAK/FAIL output format, and the prioritized fix list. It also discloses pricing. It does not detail rate limits or exact response structure, but the additions are meaningful beyond the annotations.

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

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

The description is compact and front-loaded with the key value proposition: one-call posture audit with PASS/WEAK/FAIL. Every clause earns its place, including the specific checks, the use cases, and the pricing. There is no redundant filler.

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

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

Given one simple parameter and no output schema, the description explains the verdict categories, the checks performed, and the deliverable (fix list). It gives an agent enough context to select and invoke the tool correctly without needing 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 description coverage is 100% and there is only one parameter (domain), so the schema already fully documents it. The description confirms 'for a domain' but does not add meaningful new parameter semantics beyond what the schema provides, placing it at the 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 states a clear purpose: a DNS/email security posture audit producing PASS/WEAK/FAIL verdicts. It names concrete checks (SPF, DMARC, MX, CAA, DNSSEC, nameserver redundancy) and a prioritized fix list. This clearly distinguishes it from single-purpose siblings like dns_lookup or email_domain_check.

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 says it is for 'security, deliverability and compliance automation', giving clear context for when to use it. It does not explicitly name sibling alternatives or exclusions, but the 'bundle' framing and the checks listed make the intended use case evident.

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 carry readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral details beyond annotations: the exact components included, output format (JSON), and pricing ($0.02 USDC via x402). This gives an agent a realistic expectation of scope and cost, though it does not mention rate limits or pagination, which are less relevant for a single-domain bundle.

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 compact sentence that front-loads the tool's purpose, enumerates the bundle components, states the intended audience, and includes price. Every clause contributes distinct information; there is no filler or repetition. It is dense but highly scannable.

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

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

For a tool with one required parameter and no output schema, the description adequately explains what the call returns (JSON covering RDAP, email deliverability, and threat reputation). It also conveys cost and use cases. It does not specify the exact JSON structure, but the listed categories are sufficient for an agent to decide and invoke the tool correctly. The presence of pricing is a nice addition for decision-making.

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 already has 100% description coverage for the single 'domain' parameter ('domain name to vet'), so the baseline applies. The description reinforces the meaning by saying 'vet a domain' but adds no new semantic detail about the parameter format (e.g., whether it should includewww or protocol). This is not a gap, but the description does not improve on 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 states a specific verb ('vet') and resource ('a domain') and enumerates the three bundled data areas: registration/RDAP intel, email deliverability (MX/SPF/DMARC), and hosting-IP threat reputation. This clearly distinguishes it from siblings like dns_lookup or email_domain_check, which cover only single aspects. The phrase 'bundle' reinforces that this is an aggregate tool.

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 concrete use cases ('For counterparties, sellers, links'), which tell an agent when this tool is appropriate. It does not explicitly name alternatives or when-not-to-use conditions, but the use-case guidance is clear enough to select it over single-purpose siblings. A minor improvement would be an explicit 'use instead of domain/email_domain_check when you need all three checks 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?

Annotations already indicate read-only and non-destructive behavior. The description adds valuable behavioral context: it names the data source (World Bank Open Data), discloses the price, and clarifies that the output includes which country's figure is higher for each metric. This goes beyond what annotations provide, though it does not describe output formatting or edge cases.

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 front-loaded with the core purpose, followed by specific metrics, source, usage requirement, and price. Every element adds useful information for an agent deciding whether to call this 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 simple comparison tool with two fully documented parameters and no output schema, the description adequately explains the input, the metrics returned, and the comparison behavior. It could be slightly more complete by mentioning output format or data-year caveats, but it is sufficient for correct selection and invocation.

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

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

Schema coverage is 100%, with both parameters already fully described as ISO country codes with examples. The description merely restates 'pass two ISO country codes' and adds no deeper parameter semantics, so the schema is doing the heavy lifting.

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: compare two countries' key economics in one call, listing the exact metrics (GDP, GDP per capita, GDP growth, inflation, population) and the comparison output. It clearly differentiates itself from single-country or data-lookup siblings like econ_country_snapshot and econ_worldbank.

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 use case is implied strongly: call this tool when a side-by-side comparison of two countries' economic indicators is needed. However, it does not explicitly state when not to use it or mention alternatives such as econ_country_snapshot for a single country or econ_worldbank for broader 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: it fuses indicators into one response, uses latest available data, attributes the source to World Bank Open Data, and discloses the price. This goes beyond what the annotations provide, though it does not describe the exact response structure or update frequency.

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 front-loaded with the tool's purpose, followed by specifics on indicators, source, input, and price. Every sentence adds relevant information with 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?

For a single-parameter, read-only tool, the description provides the essential operational details: what data is returned, source, input format, and cost. It lacks an explicit return-shape description, but the listed indicators effectively communicate the expected content.

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 covers 100% of parameter semantics by describing the country parameter as an ISO2 or ISO3 code with examples. The description adds only a redundant instruction to pass an ISO country code; the indicator list is context but does not deepen parameter meaning.

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 ('snapshot') and resource ('ountry economic indicators'), listing the exact indicators and stating it is a bundle fused into one response. It distinguishes itself from broad tools like econ_worldbank by emphasizing one-call, consolidated output for a country.

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 phrase 'one call' implies this is the efficient single-call option for a country's key economic indicators, and 'pass an ISO country code' signals the input requirement. However, it does not explicitly state when to choose this tool over alternatives such as econ_worldbank or other snapshot 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 already mark this as read-only and non-destructive. The description adds meaningful behavioral context: it calls the World Bank API, returns JSON, and costs $0.005 USDC via x402. It doesn't detail response structure or error handling, but the annotation coverage lowers the bar.

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 compact sentence packs the purpose, scope, source, format, and pricing with no wasted words. The key information is front-loaded, and every clause adds value.

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 read-only lookup with two well-documented parameters and strong annotations, the description is nearly complete. It specifies the output format as JSON but doesn't describe the exact response shape or failure behavior; still, the stated purpose and source are enough for an agent to invoke it correctly.

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

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

Schema descriptions already cover both parameters with ISO2/ISO3 and an indicator code example. The description's examples of indicator categories are illustrative but not essential; no meaningful semantic information is added beyond the schema, so the baseline 3 applies for 100% 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 states a specific verb ('lookup') and resource ('World Bank indicator ... for a country'), with illustrative examples of indicator types. It clearly identifies the World Bank API as the source, distinguishing it from any sibling tool, none of which offer World Bank data.

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 use when needing the latest World Bank indicator value for a country, and 'Latest value' sets an expectation of current data. It doesn't explicitly name alternatives or exclusion conditions, but no sibling tool covers the same domain, so the context is sufficient.

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

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

Annotations already mark it as read-only, non-destructive, and open-world. The description adds meaningful behavioral context beyond that: it performs MX, SPF, and DMARC lookups over DNS-over-HTTPS, returns a deliverability summary in JSON, and costs $0.003 USDC. This gives the agent a sense of what the tool actually does at runtime without contradicting the annotations.

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

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

The description is short and information-dense: it conveys purpose, method, output format, and price in three compact fragments. The structure is front-loaded with the core purpose. Slight awkwardness in the 'JSON. Price.' fragment prevents a perfect score, but every element earns its place.

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

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

For a tool with one required parameter, no output schema, and read-only annotations, the description covers the essential context: what is checked, how, the output format, and the cost. It does not describe what the 'deliverability summary' contains or how to interpret it, but that gap is minor given the simple input and the presence of the JSON return.

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 a single required parameter 'domain' with a clear description and an example ('gmail.com'), giving 100% schema coverage. The description mostly restates the domain concept and doesn't add new parameter-level details such as accepted formats or normalization behavior, so it stays at the baseline.

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

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

The description opens with a specific verb+resource: 'Email domain deliverability check', then defines what that means with a concrete question ('Can this domain receive mail, and is it configured seriously?') and the concrete checks performed (MX, SPF, DMARC). This clearly distinguishes it from generic tools like dns_lookup or domain.

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 context for when to use it: when you need to evaluate whether a domain can receive email and how seriously it's configured. However, it does not explicitly state when NOT to use it or name alternatives (e.g., dns_lookup for raw DNS records), leaving the exclusion logic 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=true and destructiveHint=false, and the description adds meaningful behavioral context beyond that: the verdict scale, 0-100 risk range, the exact data sources fused, the one-call bundling behavior, and the per-call price. No contradiction with the annotations.

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

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

Three dense, purposeful sentences deliver verdict/risk, data sources, use case, and price without filler. The most decision-relevant 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?

There is no output schema, so the description correctly covers the return values (verdict + risk) and enough behavioral context to choose the tool. However, it does not resolve how to provide email vs domain when both are listed as required, which is important for actually calling it successfully.

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 of 3 applies. The description only echoes the 'email or domain' idea and does not clarify the tension between the required[] listing both fields and the 'or use domain' phrasing, leaving an invocation ambiguity.

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

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

The description states a precise output (TRUST/REVIEW/REJECT verdict plus 0-100 risk) for an email address or sending domain, and names the fused data sources (SPF/DMARC, RDAP, hosting-IP threat reputation). This clearly distinguishes it from narrower sibling tools like dns_lookup or email_domain_check.

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 explicitly scopes the tool to 'agents filtering inbound mail, leads and senders before acting,' which provides strong context for when to use it. It does not name sibling alternatives or state when not to use them, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: authoritative source (openFDA), response format (JSON), and cost/payment mechanism ($0.005 USDC via x402). It does not disclose rate limits or error behavior, but the added context goes beyond what annotations provide.

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

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

Every element earns its place: purpose, input scope, key data fields, source, format, and price are all compressed into one efficient sentence. No filler or repetition. The structure front-loads the core purpose before supplementary details.

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

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

For a single-parameter read-only lookup with no output schema, the description covers the essential context: what data comes back, what input is expected, source, format, and cost. It is missing details on fallback behavior for unknown drugs and exact response shape, but these are minor for such a simple 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 description coverage is 100% for the single parameter 'name' ('brand or generic drug name'). The description repeats this same semantic, reinforcing it but not adding new meaning. Baseline 3 is appropriate because the schema already carries the full parameter documentation.

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 ('lookup') and resource ('FDA drug label'), with clear scope: drug by brand or generic name, covering indications, warnings, and dosage. It distinguishes itself from siblings like fda_recalls by focusing on label content rather than recall events. The purpose is immediately unambiguous.

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

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

The description clearly implies when to use: when you need official FDA label data for a named drug. It does not explicitly name alternative tools for similar lookup needs (e.g., health_drug_brief, fda_recalls), but the scope 'by brand or generic name' and the mention of label-specific fields provide sufficient context. Lacks explicit exclusions or when-not-to-use guidance.

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

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

Annotations already mark it read-only and open-world. The description adds useful behavioral context beyond annotations: the source is openFDA, the result format is JSON, and there is a specific per-call price. It does not cover rate limits or response shape, but the read-only nature lowers the burden.

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

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

The description is short and front-loaded with the core purpose, then adds source, format, and price. There is minor redundancy among 'FDA recall search', 'Search US FDA enforcement recalls', and 'Source: openFDA', but overall every sentence contributes useful 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?

For a simple read-only tool with three parameters and no output schema, the description covers the query scope, categories, source, output format, and cost. It does not describe the exact response structure, but that is not essential for correct invocation.

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

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

Schema description coverage is 100%, so the schema already explains q, type, and limit. The description lightly reinforces q as a free-text query and names the type values, but it does not add substantive meaning 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?

The description uses a specific verb ('Search') with a precise resource ('US FDA enforcement recalls') and the categories drugs, food, and devices. This clearly distinguishes it from sibling tools like fda_drug_label because it targets recalls, not labels.

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 context: use it for FDA enforcement recall lookups across drug/food/device categories. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a full 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those annotations: this is a premium paid call costing $0.20 USDC via x402, returns JSON, and produces a bundled report. No contradiction with the annotations was found.

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 well organized: the core bundle concept is front-loaded, the included report modules are enumerated compactly, and the input format, output format, and price all appear in a few short phrases. Every clause 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?

Despite having no output schema, the description sufficiently communicates what the report contains, the accepted input (ticker or CIK), the response format (JSON), and the cost. It does not spell out the exact JSON structure or any rate limits, but for a single-parameter bundled report tool, this is a reasonably complete picture.

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%: the id parameter already states 'ticker (AAPL) or 10-digit CIK.' The description repeats 'Ticker or CIK' without adding format, validation, or usage details, so it provides no real semantic value beyond what the schema already offers.

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 resource and deliverable: a bundled Company 360 report for a public company. It enumerates the report's components (financial-health verdict, insider-trading signal, SEC facts/filings) and signals this is the comprehensive 'full equity picture' option, which distinguishes it from single-purpose siblings like finance_health_scan and sec_company_snapshot.

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 phrase 'One premium call' gives clear context that this tool consolidates multiple data areas into a single paid call, implying it is the right choice when a comprehensive equity picture is needed. It does not explicitly name alternatives or state when not to use it, but the bundled positioning makes the intended use reasonably clear.

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 destructiveHint, and the description adds useful non-obvious context: this is a paid $0.50 USDC x402 call, it draws on SEC EDGAR and sanctions screening, and it returns a three-value posture. No contradiction with annotations.

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

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

One dense sentence front-loads the product type and output posture, then lists data sources and price with no filler. Every clause contributes selection-relevant 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?

For a tool with no output schema, the description covers the core output, input scope, data sources, optional peer parameter, and cost. It does not detail the brief's exact structure or how the posture is derived, but it is sufficient for an agent to decide 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 description coverage is 100%, so the schema already documents id as ticker or CIK and peer as optional comparison ticker or CIK. The description's mention of 'optional peer comparison' only restates what the schema already says, adding no new parameter semantics.

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 produces an 'Investment diligence brief' with a CONSTRUCTIVE/NEUTRAL/CAUTION posture for a public company, and enumerates the fused data sources: financial-health, insider activity, optional peer comparison, and issuer sanctions screening. The 'bundle' framing distinguishes it from narrower sibling tools, though it does not explicitly name them.

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: use this one-call tool when you need a fused diligence view of a public company. However, the description provides no explicit when-to-use versus when-not-to-use guidance and does not name sibling alternatives, so the agent must infer selection from the bundle description.

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 establish read-only and non-destructive behavior. The description adds meaningful context beyond those annotations: it performs a bundled multi-part scan, pulls from SEC EDGAR, returns JSON, and costs $0.05 USDC via x402. This is useful operational 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 dense sentence with no wasted words. It front-loads the purpose and output, then packs input, source, format, and price into a compact, scannable form.

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 one parameter and no output schema, the description covers everything needed to call it correctly: input type, data source, return format, pricing, and the nature of the output verdict. Nothing essential is missing.

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

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

The input schema already documents the single parameter with the ticker example and 10-digit CIK format. The description merely repeats 'Ticker or CIK,' adding no new semantic detail beyond what the schema provides.

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 resource (public company), the data inputs (revenue/margin trend, current ratio, profitability, material filings), and the distinctive deliverable (healthy/watch/distress verdict). This distinguishes it from filing-specific tools like sec_filings_search and general snapshots like sec_company_snapshot.

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 'bundle' and 'One call' phrasing imply this is the consolidated tool for a financial-health verdict, and it clearly gives the input forms (ticker or CIK). However, it never names sibling tools or states when to choose this over finance_company_360, finance_peer_compare, or sec_filings_search.

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 indicate this is read-only and non-destructive. The description adds valuable behavioral context by revealing it is a bundled one-call API, uses SEC EDGAR, returns JSON, costs $0.05 USDC via x402, and produces a synthesized insider signal. This goes beyond what the annotations alone convey.

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 with useful facts—time window, data source, output fields, signal type, pricing, and payment rail—without filler. Each segment earns its place, and the key scope statement 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?

For a single-parameter tool with no output schema, the description covers the essential context: input format, time range, data source, contents of the result, signal synthesis, and cost. It does not spell out the exact JSON response shape, but the level of detail is sufficient for an agent to invoke it correctly.

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

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

The only parameter, id, is already fully described in the schema as 'ticker (AAPL) or 10-digit CIK', which matches the description's mention of 'Ticker or CIK'. Since schema coverage is 100%, the description adds little semantic value beyond what the input schema provides.

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 recent SEC Form 4 insider transactions for a public company, including who bought/sold, share counts, dollar value, and a netted bullish/bearish/neutral signal. This distinguishes it from broad SEC filing search tools and company financial tools among the 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 context for when to use the tool: when recent insider trading activity over the last ~120 days is needed, accepting a ticker or CIK. It does not explicitly name alternative tools or state when not to use it, but the input scope and purpose are sufficiently clear for an agent to route requests correctly.

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

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

Annotations already declare the tool read-only and non-destructive, lowering the bar. The description adds meaningful behavioral context: it is a single premium call sourced from SEC EDGAR, returns JSON, and costs $0.20 via x402. It does not cover rate limits or auth details, but it goes beyond what annotations alone provide.

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

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

The core purpose is front-loaded and the rest of the description packs useful details—metrics, source, format, and price—into one dense sentence. There is no filler, though the long metric list makes it slightly heavier than necessary.

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, the description takes on the job of explaining return values and does so at a useful level: it names the metrics compared, per-metric winners, the financial-health verdict, and the 'stronger financial profile' call. Minor operational details like error handling are absent, but they are not critical for this simple two-parameter read-only 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 description coverage is 100%, and the schema already documents that a and b are company tickers or CIKs with examples. The description repeats 'Two tickers or CIKs' but adds no new parameter semantics 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?

The description names a highly specific action: comparing two public companies head-to-head, and enumerates the exact metrics and verdicts produced. This clearly distinguishes it from single-company finance siblings like finance_company_360 or finance_health_scan, even without naming them.

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 use case is implied: use this tool when you need a side-by-side peer comparison of two public companies on revenue, net income, margins, growth, and financial health. It does not explicitly state when not to use it or name alternatives, so the guidance remains implicit rather than fully explicit.

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 destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond those: data source (USGS), response format (JSON), one-call bundling, pricing, and the specific output elements.

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 front-loaded, with the core deliverable stated first, followed by use cases, source, format, and price. Every phrase earns its place without 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?

With no output schema, the description compensates by naming the expected result elements: count, largest magnitude, list, and risk level. It also covers source, input mode, and price. It does not explain the risk-level scale or output structure in detail, but it is adequate for invocation.

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

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

Input schema coverage is 100%, so every parameter is already documented. The description reinforces the address-or-lat+lon choice and radius but does not need to add more; baseline 3 is appropriate since the schema carries the semantic weight.

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 bundled deliverable: a seismic risk brief for a US point yielding recent earthquake count, largest magnitude, list, and risk level. It clearly distinguishes this from sibling geo tools by emphasizing seismic risk rather than general location or geocoding.

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: use for a US point via address or lat+lon, and names target use cases (insurance, siting, diligence). It does not explicitly name alternatives or exclusions, but the scope is sufficiently specific to guide selection.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds valuable context beyond annotations: the US Census Bureau source, JSON response format, and per-call cost. It does not disclose edge cases like unmatched addresses, but the annotation coverage lowers the burden.

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 front-loaded with the core purpose, followed by brief source, format, and pricing details. Every fragment earns its place, with no redundant filler.

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

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

For a simple single-parameter read-only tool, the description is largely complete: it defines input, output, source, format, and cost. It does not spell out behavior for invalid or unmatched addresses, but the schema and annotations handle the essential selection and safety 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 description coverage is 100% for the single address parameter, so the description need not add much. It reinforces that the input is a US street address but does not add details beyond 'one-line US address' already present 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 states a specific operation — US street address geocoding to coordinates plus matched/normalized address — and identifies the data source. This clearly distinguishes it from sibling tools like geo_reverse and geo_location_brief.

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 clearly implies use for US addresses needing geocoding, but it does not explicitly state when to prefer this over alternatives such as geo_reverse. There is no when-not guidance or named alternative.

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 non-destructive. Description adds valuable context: JSON output, USD C pricing via x402, US-only scope, and the bundled response contents. It doesn't cover rate limits or auth, but annotations lower that burden.

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?

One dense, front-loaded sentence conveys purpose, inputs, output components, format, and price. No filler or repeated schema content.

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

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

For a tool with no output schema, the description adequately explains return categories, input alternatives, scope, JSON format, and price. The address-required conflict and lack of explicit sibling guidance are the main 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 coverage is 100% so a 3 baseline would normally apply, but the description's 'address OR lat+lon' claim conflicts with the schema, which requires address. This is actively misleading for an agent deciding whether to pass coordinates 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?

Description clearly defines a bundled US-place lookup: normalized address, county/state, current conditions, and active alerts in one call. The 'bundle' phrasing distinguishes it from sibling geocoding and weather tools, even though it doesn't name them.

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?

Description communicates when to use it: when you need a US place's location details plus current weather and alerts in a single call. It does not explicitly name alternatives or exclusion cases, so it stops 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?

Annotations already establish the tool as read-only and non-destructive. The description adds valuable behavioral context: Census as the authoritative source, JSON as the response format, and a unit price of $0.002 USDC, which helps an agent assess cost and trustworthiness. It does not disclose rate limits or coordinate format expectations, but it also does not contradict the annotations.

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

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

The description is extremely concise and well-structured: purpose is front-loaded, followed by source, format, and price in short declarative fragments. Each segment adds distinct information with 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?

For a two-parameter read-only tool, the description provides sufficient context: geographic scope, source, output geography, response format, and cost. With no output schema, it still hints at what the response contains, though field names and coordinate precision are unspecified. Overall it is complete enough for correct selection and invocation.

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

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

Both parameters are fully documented in the schema with simple descriptions ('latitude', 'longitude'), giving 100% schema coverage. The description does not add parameter-level detail such as coordinate format (e.g., decimal degrees) or valid ranges, so the baseline score 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 defines the operation: coordinates are converted into US state, county, tract, and block geography using Census data. The 'Coordinates to ...' phrasing states the resource and output scope, distinguishing it from forward geocoding tools like geo_geocode. Although it opens with a title-like phrase, the full description conveys a specific, actionable purpose.

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

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

The description explicitly sets geographic scope (US) and source (Census Bureau), allowing an agent to infer this is for US reverse-geocoding tasks. However, it does not mention sibling tools such as geo_geocode or state when not to use this tool, so usage guidance is implicit rather than explicit.

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 destructiveHint=false; the description adds useful behavioral context: it consults active NWS alerts, returns a severity summary and verdict, and costs $0.03 USDC. Nothing in the description contradicts the annotations.

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

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

Three compact sentences with no filler: the scan scope, output verdict, intended use cases, input alternatives, and price are each one clause. The decision-critical 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?

For a read-only scan without an output schema, it conveys enough retrieval semantics: active NWS alerts, US state or point, severity summary, verdict, and highest event. It could be more explicit that coordinate mode requires both lat and lon despite the schema's required flags, but the description suffices for tool selection and invocation.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds 'Pass state (e.g. TN) or lat+lon', which signals coordinates must be paired together. However, the input schema marks all three parameters as required, so the description and schema conflict on whether state OR coordinates are sufficient, weakening the value this adds.

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 states a specific verb and resource: one call for active NWS watches/warnings/advisories for a US state or point, summarized by severity with a CLEAR / MONITOR / CAUTION / AVOID verdict and the highest active event. This clearly differentiates it from sibling weather_alerts, which is a plain alert tool, by emphasizing the bundle and operational verdict.

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 frames usage contexts: logistics, field ops, and travel automation, which tells an agent when the bundle is relevant. It does not name alternatives or say when not to use it, so it stops short of the highest bar.

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, openWorldHint=true, and destructiveHint=false. The description goes beyond these by specifying the data source (ClinicalTrials.gov), output format (JSON), cost and payment mechanism ($0.05 USDC via x402), and the time scope ('recent'). It also notes 'One call', implying a bundled, non-paginated response. These are useful behavioral details beyond the annotations.

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

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

The description is compact and well-structured, with the tool name and core purpose front-loaded. Each segment adds distinct value: scope, return fields, source, use case, output format, and pricing. No filler or redundant phrasing.

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?

Even though there is no output schema, the description compensates by listing the exact response fields (NCT id, title, status, phase, sponsor, last-update date), the source, and the pricing. For a read-only search tool with two optional parameters, this is sufficient information for an agent to invoke it correctly and understand the result.

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

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

Schema description coverage is 100%, with both condition and intervention already described. The description's phrase 'condition and/or intervention' clarifies that the parameters can be combined, but it does not add meaningful syntax or format details beyond what the schema already provides. 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 states a specific verb and resource: 'Clinical trials search' for ClinicalTrials.gov trials. It enumerates the returned fields (NCT id, title, status, phase, sponsor, last-update date), making the output clear and distinguishing this tool from siblings like fda_drug_label or fda_recalls simply by domain and source.

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 broad context ('For pharma, research, diligence') and implies usage for finding recent trials by condition and/or intervention, but it does not explicitly state when to use this tool instead of alternatives such as fda_drug_label or fda_recalls, nor does it mention any exclusions or fallback 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?

Beyond the annotations (readOnly, non-destructive, openWorld), the description adds valuable behavioral context: it returns reference data, is not medical advice, outputs JSON, and costs $0.05 USDC via x402. These details help an agent set expectations about safety, format, and cost. No contradictions with annotations.

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

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

A single, well-structured sentence packs all essential information: scope, included data sources, output format, disclaimer, and pricing. The main descriptor is front-loaded, and every element earns its place. No fluff or redundant repetition of schema details.

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 tool, the description covers the input, the output content, the format, and cost. It does not detail the exact JSON shape or error handling, but given there is no output schema, the high-level content list is sufficient for an agent to invoke it correctly. Minor gap: no mention of what happens for unknown drug names.

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 the parameter description 'drug brand or generic name'. The tool description adds little beyond that, mentioning 'a medication' but not specifying format variants, case sensitivity, or examples. Baseline 3 is appropriate since schema handles parameter semantics adequately.

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 delivers: a bundled drug safety brief with RxNorm identity, FDA label safety sections, and FAERS adverse reactions. It uses a resource-focused phrasing ('One call for a medication') and lists concrete components, making it easy for an agent to distinguish from sibling tools like fda_drug_label. The 'bundle' designation signals comprehensive coverage in a single call.

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 conveys when to use this tool: when a comprehensive medication safety overview is needed in one call. It does not explicitly name alternatives or exclusion conditions, but the 'one call' phrasing implies it is the integrated option versus more focused tools. Clear context without explicit when-not guidance.

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

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

Annotations already mark readOnly and non-destructive; the description adds meaningful behavior beyond that: it sources from openFDA, returns brand/generic and warning data, flags shared generics, and includes price and disclaimers. No annotation contradiction.

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

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

The description is dense and informative, with purpose, scope, source, exclusions, and price in a compact parcel. The opening 'Drug safety compare (bundle)' repeats the tool/title, but only minor 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?

There is no output schema, so the description does the necessary work of explaining what the caller gets: side-by-side label safety, indications/warnings per drug, and shared-generic flag. It also covers source, cost, and exclusions, making it sufficiently complete for a simple two-parameter read-only 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 description coverage is 100% (a and b are both 'first/second drug (brand or generic)'), so the description adds little beyond the schema. It reinforces that both drugs are accepted as brand or generic, but does not add formatting, era, or disambiguation details.

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 it compares FDA label safety for two drugs side-by-side and lists the specific outputs (brand/generic identity, indications, warnings, shared-generic flag). This distinguishes it from single-drug or other health tools in the sibling list, even without explicitly naming them.

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 excludes drug-interaction analysis and medical advice, which helps an agent avoid misusing it. It implies use for side-by-side safety comparison rather than single-label lookups, though it does not name an alternative sibling like fda_drug_label.

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

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

Annotations already mark the tool as read-only and non-destructive; the description adds value by disclosing the data source (RIR RDAP), the response format (JSON), and the $0.003 USDC cost via x402. It does not cover rate limits or failure modes, but for a single-parameter read-only lookup 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 compact, front-loaded single line that packs the function, output fields, source, format, and price with no filler. Every clause contributes meaningful 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 one required parameter fully described in the schema and annotations covering the safety profile, the description supplies the remaining necessary context: returned fields, data source, response format, and cost. It does not detail output structure or error conditions, but that is not essential for such a simple lookup.

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 fully documents the single 'ip' parameter as an IPv4 or IPv6 address at 100% coverage, so the baseline is 3. The description does not add extra parameter syntax, formatting constraints, or edge-case guidance beyond what the schema already provides.

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 lookup function: identifying who operates an IP address via RDAP, and lists the returned attributes (registry, network range, organization, country). This clearly distinguishes it from sibling tools like dns_lookup or threat_ip, despite the generic tool name 'ip'.

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 the use case — determining the operator of a given IP address — which provides enough context to route an agent to this tool over DNS or threat-intel siblings. However, it does not explicitly name alternatives or state when not to use this tool.

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

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

Annotations already mark it as read-only and non-destructive. The description adds useful behavioral context: the result contains a normalized verdict and score, the underlying intelligence sources, and that the call costs $0.08 USDC via x402. This goes beyond the annotations without contradicting them.

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

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

The description is a single dense sentence that front-loads the core outcome and then enumerates the bundled data sources. Every clause carries useful information, including the explicit pricing detail, with no filler 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?

With no output schema present, the description does the necessary work of explaining what the agent will get: a verdict, a numeric score, and a fused source set. It could add more about output format or interpretation of the score direction, but for a single-parameter read-only tool it is largely complete.

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

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

The input schema fully documents the single 'ip' parameter as 'IPv4 or IPv6 address to assess', and the description only repeats that it applies to an IP. Since schema coverage is 100%, the description is not required to add much, and it does not meaningfully extend the parameter explanation.

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 resource (IP) and a specific deliverable (ALLOW/REVIEW/BLOCK verdict + 0-100 score), and distinguishes itself as a 'bundle' that fuses multiple data sources. This clearly separates it from simpler sibling IP tools like ip or threat_ip.

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 'One call' phrasing and the bundled-source framing imply use when a consolidated IP risk verdict is needed. However, it never explicitly says when to choose this over siblings such as security_threat_lookup, threat_ip, or security_bulk_ip_screen, nor does it state any exclusions or fallback conditions.

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 signal read-only and non-destructive behavior. The description adds useful behavioral context: it returns the 'most recent' matching documents, includes agency/type/date/abstract, returns JSON, and has a specific price. This supplements the annotations without contradicting them.

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

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

The description is compact and front-loaded, immediately stating the tool's value ('One call') and core output. Every sentence adds useful information including source, fields, optional filter, use case, format, and price, with 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?

Given no output schema, the description adequately covers what the tool returns and its purpose. It lacks detail on pagination, result limits, or the exact time window for 'most recent,' but these are minor gaps for a simple 2-parameter read-only 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 description coverage is 100%, so the schema already documents both 'topic' and 'agency' with examples. The description only restates the optional agency filter and topic matching; it does not add meaningful parameter semantics 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?

The description identifies a specific resource (recent US Federal Register documents), a specific scope (matching a topic), and the returned fields (agency, type, date, abstract). This clearly distinguishes it from sibling tools focused on SEC filings, FDA labels, or sanctions 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 states a clear use case: 'For compliance monitoring.' It also indicates the data source and that an optional agency filter is available, giving an agent enough context to select this tool. It does not explicitly name alternatives or exclusions, but the intended context is clear.

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 destructiveHint=false; the description adds meaningful behavioral detail: it screens 'with aliases', returns 'match/no-match, which list, programs, and a clear/review/hit verdict', and outputs JSON. It also discloses the bundled nature and price, going beyond the annotations and giving the agent a clear picture of results. Minor gaps remain (e.g., no mention of data freshness or interpretation of 'review'), but it is solidly 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 dense but well-organized: the core action and bundle concept lead off, followed by covered lists, output details, use case, format, and price. Every element is functional and there is no filler, though the long em-dash chain makes it slightly heavy to parse and could be split into cleaner sentences.

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 only two parameters and no output schema, the description covers the essential context: the exact screening lists, the verdict format, the use case, and the output format. It is complete enough for an agent to decide to call it and interpret a basic response. It doesn't explain edge cases like name variations or ambiguity handling, but the provided detail is strong.

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 reinforces that 'name' is a person or company name, matching the schema, but it adds no new meaning for the 'type' parameter beyond what the schema already states. It does not compensate with extra format or usage details, so it stays 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 clearly states a specific action ('screen a person or company name') against a specific resource (US Consolidated Screening List) with named sub-lists and an output verdict. It is unambiguous about what the tool does, though it does not explicitly contrast itself with sibling tools like trade_party_screen or legal_reg_watch, so it just misses the top score for sibling differentiation.

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 a clear usage context ('For KYC and onboarding') and specifies the applicable scope (sanctions/watchlist screening), which tells an agent when this tool is relevant. However, it does not state when not to use it or mention alternative tools, so it lacks explicit exclusions or comparisons.

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 the safety profile (readOnlyHint=true, destructiveHint=false), so the bar for added behavior is lower. The description goes beyond them by disclosing a concrete cost ($0.05 USDC via x402), a geographic constraint (US points only), the output format (JSON), and behavioral scope details — that weather is fetched at both endpoints and results are fused into a go/caution verdict. No contradiction with annotations; the only omissions are peripheral (rate limits, data freshness).

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 zero filler. The purpose and composite scope are front-loaded in the first clause, the enumerated components follow in a tight list, and practical details (format, price) close it out. Every word earns its place — notably, the title annotation is fully redundant with the description, so there is no duplication to cut.

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, the description carries the burden of conveying what comes back, and it covers all the essentials: distance, time, fuel cost, weather, active alerts, the fused verdict, and JSON format. Input format and defaults are delegated to the 100%-covered schema. Minor gaps remain — units for distance/time are unstated, and it doesn't clarify whether one route or alternatives are returned — but for a moderately complex bundle tool, the coverage is largely adequate.

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%, setting a baseline of 3, but the description contributes real semantic value beyond the schema: it reveals why mpg matters (it feeds the estimated fuel cost — the schema merely labels it 'optional vehicle MPG'), and it adds the US-only scope that constrains how origin and dest values should be interpreted. This transforms the parameters from syntax into an economic and geographic model.

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

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

The description opens with a concrete composite deliverable ('Route & shipment brief (bundle)') and enumerates exactly what one call produces: driving distance and time, estimated fuel cost, weather and active alerts at both ends, fused into a go/caution verdict. The specific enumeration of components ('bundle', 'One call') distinguishes it unmistakably from single-purpose siblings like weather_alerts, geo_geocode, and vehicle_fuel_economy, whose scopes it subsumes.

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 phrase 'One call' and 'bundle' imply this is the consolidated alternative to making several separate single-purpose calls, and the component list communicates its coverage. However, it never explicitly names alternatives such as weather_alerts, weather_current, geo_geocode, or vehicle_fuel_economy, nor states when an agent should prefer those instead (e.g., when only weather or only a geocode is needed). The usage context is implied, not prescribed.

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 signal readOnly and non-destructive behavior, so the description adds value by disclosing that this is a priced premium call ($0.15 USDC) and that outputs are JSON with a fused hazard verdict and factors. It does not cover every behavior such as rate limits or exact response shape, but the important operational traits are 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 a single dense sentence that front-loads the tool identity and bundling value, then lists components, use cases, output format, and price. Nothing is filler, though the long run-on structure makes it slightly harder to parse than necessary.

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?

Without an output schema, the description still gives a useful preview of the response: JSON, combined sources, overall hazard verdict with factors, plus input modes and pricing. It could be more explicit about the required-address constraint or expected hazard verdict scale, but it is sufficient for an agent to decide whether to call 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?

The input schema already documents all three parameters, and the description largely restates the address-or-lat+lon relationship found in the schema. It adds the 'US property' scope, but it leaves the required-address-versus-optional-lat/lon ambiguity unresolved, so it does not meaningfully improve on 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 names a specific deliverable — a bundled property hazard report for a US property — and enumerates the exact data sources (FEMA flood, USGS seismic, weather, alerts) and the fused hazard verdict. This clearly distinguishes it from generic weather, earthquake, or geocoding siblings and from the similarly named realestate_site_risk tool.

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 when to use it: for insurance, lending, and siting decisions, with an input mode of address or lat+lon. It does not explicitly contrast it with alternatives or say when not to use it, but the use-case framing and 'one premium call' bundling provide clear situational 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?

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds meaningful behavior: exact data components, the fused verdict nature, JSON output, and cost via x402. It does not describe edge cases like handling both address and lat/lon, but the disclosed behavior goes well beyond the annotations.

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

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

The description is compact and front-loaded: purpose, input mode, outputs, use cases, format, and price in two dense sentences. No filler or repeated schema content weakens it.

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, the description does a good job enumerating the expected result components (FEMA SFHA, county/state, conditions, alerts, verdict) and pricing. It lacks detail on exact verdict values or error behavior, but for an agent deciding whether to call and what to expect, it is largely 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 coverage is 100%, so the baseline is 3. The description adds value by explicitly framing 'address OR lat+lon' as an either/or choice, which the schema only implies, and by clarifying the US-property scope. This is a small but useful semantic improvement over 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 identifies the tool as a property site-risk bundle for US properties, combining FEMA flood-zone data, county/state, conditions, and weather alerts into a fused verdict. This distinguishes it from siblings like realestate_property_report, weather_current, and geo_location_brief by emphasizing the bundled, risk-focused output.

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 states explicit use cases ('For lending, insurance, diligence') and frames the tool as a one-call bundle, implying it replaces multiple separate calls. It does not name alternative tools or provide exclusion criteria, so it stops short of full routing guidance.

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

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

Annotations already establish read-only, non-destructive, open-world behavior, so the description does not need to restate that. It adds valuable behavioral context: the output posture values, the specific fused data sources, geographic scope, and a $0.40 USDC price. No contradiction with readOnlyHint or openWorldHint.

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 tight sentences deliver the purpose, output, data sources, geography, and pricing with no filler. The key outcome is front-loaded before the supporting detail.

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, the description still explains what the agent will get back (STANDARD/SURCHARGE/REFER), what data is combined, and what geographic scope applies. Combined with read-only annotations and full schema parameter documentation, the agent has enough 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 the baseline is 3. The description does not add per-parameter detail beyond reinforcing the US-address input; address, lat, and lon are already documented in the schema. It does not clarify the slight tension between the required-address schema and the address's '(or use lat+lon)' note, but that is a schema-level issue.

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 a specific verb-resource pair: it returns a STANDARD/SURCHARGE/REFER hazard-underwriting posture for a US property address. The 'bundle' framing and the fused data sources distinguish it from similar siblings like realestate_property_report and realestate_site_risk.

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 makes the use case clear: call this when you need a consolidated hazard-underwriting posture across flood, seismic, and weather data. It does not explicitly name alternatives or say when not to use it, but 'One call' and 'bundle' imply it should be preferred over separately querying geo/weather 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?

The annotations already establish read-only and non-destructive behavior. The description adds meaningful context beyond annotations by naming the source (SEC EDGAR), the underlying data type (XBRL filings), the response format (JSON), and the cost ($0.01 USDC via x402). This goes beyond what annotations convey.

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 front-loads the core purpose before listing source, format, and price. Minor redundancy exists because the description begins with 'SEC company facts (EDGAR)', which matches the title, and later repeats 'Source: SEC EDGAR', but overall it is efficient and well-ordered.

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

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

For a single-parameter read-only tool, the description covers the input type, data source, returned metric fields, output format, and cost. There is no output schema, so the listed fields partially compensate for the missing return structure, though it does not specify period, currency, or whether all listed facts are always present.

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 already fully documents the single parameter id as 'ticker (AAPL) or CIK number', and the description repeats this by saying 'by ticker or CIK'. Since schema description coverage is 100%, the description adds no significant parameter semantics 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?

The description clearly identifies the tool as providing SEC EDGAR company facts, specifically latest key financial metrics like revenue, net income, assets, and EPS for a US public company. It is specific about the resource and data source, though it does not explicitly differentiate itself from the closely named sibling sec_company_snapshot.

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 phrase 'Latest key financial facts... by ticker or CIK' implies the intended use case: retrieving core financial metrics for a US public company. However, it does not explicitly state when to prefer this over related siblings such as sec_company_snapshot or sec_filings_search, leaving some selection ambiguity.

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 carry the safety profile (readOnlyHint=true, destructiveHint=false), so the description's job is to add context beyond that. It does: disclosing that the tool is paid ($0.03 USDC via x402) is critical behavioral info an agent must know before invoking, and it describes the bundle composition. No contradiction with annotations.

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

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

Four distinct facts — data returned, input format, output format, and price — are packed into one compact string with zero filler. The scoping label 'Company snapshot (bundle)' is front-loaded, and every fragment earns its place.

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

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

For a one-parameter, read-only snapshot tool whose safety is already covered by annotations, the description covers the data returned, input format, output format, and cost — most of what an agent needs. The minor gap is the underspecified scope of 'most recent filings' (how many, which form types, what period), which matters more because no output schema exists to clarify 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 description coverage is 100% — the schema already documents id as 'ticker (AAPL) or CIK', and the description merely restates 'Ticker or CIK'. Per the high-coverage baseline, the description adds no meaning beyond the schema, so 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 names the resource (SEC company facts) and enumerates the specific fields (revenue, net income, assets, EPS) plus the most recent filings, so an agent knows exactly what it will retrieve. The 'bundle — One call' framing implicitly differentiates it from siblings like sec_company and sec_filings_search, but it never names those alternatives, so differentiation is left to inference rather than stated.

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?

'One call' implies the usage scenario — getting both facts and filings without a second invocation — which is a legitimate but weak usage signal. There is no explicit when-to-use/when-not-to-use guidance, and no alternatives are named even though sec_company and sec_filings_search exist in the sibling list, making the routing decision a real 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?

The readOnlyHint and destructiveHint annotations already establish this is a safe, non-destructive read operation. The description adds valuable behavioral context beyond those annotations: it names the external source (SEC EDGAR), states the response format (JSON), and discloses the financial cost ($0.01 USDC via x402), which is especially important for a paid 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 somewhat repetitive: 'SEC filings full-text search (EDGAR)' and 'Full-text search across SEC filings' state the same idea, and 'Source: SEC EDGAR full-text search' repeats it again. While all included facts (purpose, output, source, format, price) are relevant, the redundancy makes it less lean than it could be.

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

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

For a simple read-only tool with three parameters and no output schema, the description covers the essentials: what it searches, what it returns (metadata and links), the output format, the external source, and the price. It does not detail sorting or pagination, but the limit parameter partially addresses result control and the schema provides the necessary input semantics.

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 fully documents q, form, and limit. The description only paraphrases the form filter ('filter by form type') and adds no new semantic details about parameter formatting, defaults, or edge cases, leaving it at the 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 states a specific verb ('Full-text search') and resource ('SEC filings'), explicitly notes filtering by form type, and mentions the return value ('filing metadata and links'). This clearly distinguishes it from sibling tools like sec_company and sec_company_snapshot, which focus on company data rather than full-text filing search.

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 intended use is implied: search across SEC filing documents, optionally filtered by form type. However, the description does not contrast this with siblings such as sec_company or sec_company_snapshot, nor does it state when NOT to use this tool, so an agent gets no explicit routing guidance.

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

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

Annotations already signal read-only/non-destructive, and the description adds behaviors beyond those annotations: it returns per-IP verdicts and scores, a summary with counts and worst verdict, and discloses the $0.08 USDC cost via x402. This is useful operational context an agent cannot infer from schema or annotations.

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

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

The description is compact and front-loaded with the key details before use cases and price. The opening phrase 'Bulk IP screen (bundle)' is slightly redundant with the tool name/title, but the rest of each sentence earns its place.

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

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

For a one-parameter tool with no output schema, the description covers what is needed to select and invoke it: input cap, intended scenarios, output shape, and price. No critical operational information is missing.

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

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

The input schema already documents ips as 'comma-separated IPv4/IPv6 list, up to 10' with 100% coverage, so the description adds no new parameter meaning. It effectively restates the cap ('up to 10 IPs at once'), which is consistent but not additive.

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 ('screen'), a precise resource (up to 10 IPs), and the expected result (reputation/risk with ALLOW/REVIEW/BLOCK + score and an overall summary). This clearly distinguishes it from single-IP sibling tools such as ip_intelligence or threat_ip.

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 concrete use cases: firewall rules, log triage, and connection batches, which tells an agent when to choose this bulk tool. It does not explicitly enumerate alternatives or when-not-to-use cases, so it stops 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?

Annotations already declare read-only, non-destructive, open-world behavior. The description adds substantial context beyond those annotations: it discloses the $0.10 USDC x402 price, the bundled 'one call' nature, and the exact output format (grade plus findings and fix list). This gives the agent practical expectations about cost and result shape.

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 every clause earns its place: what the report is, what it fuses, what the output is, when to use it, and what it costs. The structure front-loads the headline result and then provides needed supporting detail.

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

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

There is no output schema, so the description must explain what the agent will receive; it does, naming the three health levels, the graded output, and the consolidated findings/fix list. Combined with the single required parameter, use cases, and pricing, the agent has enough context to call this 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 covers the only parameter, domain, with an adequate description. The tool description also names 'domain' as the subject but adds no syntax, format, or edge-case meaning beyond the schema. Baseline 3 applies because schema coverage is 100%.

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 precise, differentiated function: it produces a bundled domain threat report with HEALTHY/NEEDS_ATTENTION/HIGH_RISK grades, fusing DNS and email hardening signals into one grade plus findings. This clearly distinguishes it from narrower sibling tools like dns_lookup or security_threat_lookup, and it names the concrete technical inputs (SPF, DMARC, DNSSEC, CAA, nameservers).

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 identifies clear use cases — security, diligence, and vendor review — which tells an agent when to select it. It does not explicitly state when not to use it or name alternatives, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it is a one-call bundled screening operation, fuses three data sources, and has a $0.05 USDC cost via x402, which is important for invocation decisions.

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 front-loaded: it states the core action and output in the first sentence, then adds the use case and pricing. Every sentence earns its place with 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?

For a read-only screening tool with three well-documented parameters and no output schema, the description sufficiently explains what the tool does, what inputs matter, and what verdict format to expect. Pricing and target automation contexts are also included, making the tool broadly self-contained.

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 gives high-level context that maps parameters to signals (IP reputation, referer/link safety, user-agent heuristic), but it does not add detailed parameter semantics beyond what the schema already documents.

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 purpose: produce an ALLOW / CHALLENGE / BLOCK verdict for an inbound HTTP request, and identifies the fused signals (IP reputation, referer/link safety, user-agent heuristic). This clearly distinguishes it from sibling tools like security_bulk_ip_screen or url_safety by framing it as a single-call request 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?

The description gives clear usage context: 'For WAF, gateway and bot-defense automation.' It does not explicitly name alternatives or when-not-to-use conditions, but the use case is specific enough to guide an agent choosing among siblings.

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 supply read-only and non-destructive hints, and the description goes beyond them by disclosing that this is a paid call priced at $0.10 USDC via x402, and that it is a one-call bundle rather than separate lookups. It also reveals the component data sources (SPF/DMARC, redirects, domain age, hosting, IP reputation). This is useful operational context beyond what annotations convey.

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 ordered: output first, then what is fused, then intended agent use, then price. Every sentence carries useful selection or invocation information and no text is redundant with the schema. It is appropriately front-loaded for an agent scanning many tool listings.

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

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

For a single-paid-call tool with no output schema, the description provides sufficient context: expected inputs, what the tool analyzes, the return value (verdict + risk score), the intended use case, and cost. There is no critical missing information that would prevent an agent from selecting and invoking the tool correctly. The lack of explicit alternatives is minor here because the intended workflow is clearly stated.

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 description covers 100% of the parameters (email, url, ip), so the structured data already does the heavy lifting. The description adds only a loose mapping: 'sender-domain authentication' relates to email, 'destination-link safety' to url, and 'optional source-IP reputation' to ip. That is helpful orientation but not format-level semantics beyond the schema, so the 3 baseline 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?

The description states exactly what the tool does: it returns a SAFE/SUSPICIOUS/PHISHING verdict plus 0-100 risk for an inbound message by fusing sender-domain, link-safety, and IP-reputation signals. The 'bundle' framing and the mention of fused signals distinguish it from the many single-signal sibling tools like email_sender_trust, url_safety, and threat_ip. The target use case ('screening inbound email, DMs and leads') makes its 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 gives a clear context for use: agents screening inbound messages before acting on them. It does not explicitly say when not to use it or name alternatives such as using individual email/URL/IP checks instead, but the broad use case is enough to guide an agent. A small deduction for lacking explicit exclusions or alternative-tool routing.

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

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

Beyond the annotations, the description adds meaningful behavior: it auto-detects indicator type, routes to different analysis sources, returns a normalized CLEAR/SUSPICIOUS/MALICIOUS verdict with risk score and details, and costs $0.05 USDC via x402. This is useful context an agent cannot infer from readOnly/openWorld/non-destructive annotations alone.

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 front-loaded with the core 'one call, any indicator' behavior, then gives output shape and price. The opening phrase duplicates the title, but the overall structure is efficient 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?

For a one-parameter, read-only lookup with no output schema, the description covers the input types, the internal routing behavior, the returned verdict/score/details, and the pricing. 'Full details' remains high-level, but an agent has enough to invoke and interpret the result at the required level of detail.

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 already documents the single indicator parameter as 'an IP, domain, or URL to check' at 100% coverage. The description essentially restates this accepted input and adds the auto-detection behavior, but it does not add substantive new parameter-level detail beyond what the schema says.

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 a specific action and resource: pass an IP, domain, or URL and get a unified threat verdict. It also distinguishes itself from the many specialized sibling tools by calling itself the 'single entry point' bundle that auto-detects indicator type and routes to the right analysis.

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 explicitly identifies when to use this tool: any IOC, any type, because it auto-detects and routes internally. It does not name specific sibling alternatives or exclusions such as bulk screening, but 'the single entry point for checking any IOC' gives enough context for an agent to choose it over specialized lookups.

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 destructiveHint=false. The description adds meaningful behavioral details beyond that: it uses POST, runs Llama on Workers AI, returns JSON, and crucially states a cost of $0.008 USDC via x402. This pricing information is important for an agent deciding whether to invoke the tool, though it does not cover rate limits or failure behavior.

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 front-loaded with purpose, followed by protocol, model, output format, and price. It wastes little space, though 'Workers AI' appears twice ('Text summarizer (Workers AI)' and 'Runs Llama on Workers AI),' creating a minor redundancy that prevents a perfect score.

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 read-only summarizer with 2 well-documented parameters and no output schema, the description covers purpose, parameters, endpoint, model, response format, and cost. It does not specify the exact JSON response structure, but the purpose clause 'Summarize arbitrary text into a concise summary' implies what the JSON contains, so the agent can likely use it correctly.

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

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

Schema description coverage is 100%, so both parameters (text and sentences) are already documented in the schema. The description's 'POST {text, sentences?}' merely echoes the parameter names without adding new semantic meaning beyond what the schema provides. 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 verb and resource: 'Summarize arbitrary text into a concise summary.' It signals breadth with 'arbitrary text,' which loosely distinguishes it from domain-specific siblings like wiki_summary, but it does not explicitly name or contrast any sibling tool, so it falls 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?

Usage is implied through the stated purpose: use it when you need to summarize arbitrary text. However, there is no explicit guidance on when NOT to use it or which alternative tool to choose instead (e.g., ai_chat or wiki_summary), leaving the agent to infer boundaries from the sibling list.

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

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

Annotations already mark this as read-only and non-destructive; the description adds valuable behavioral detail: feed sources, inclusion of Polyform's observed scanner traffic, exact return fields, JSON format, and price. This goes well beyond the structured annotations.

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

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

Every sentence earns its place: question framing, data sources, return values, use cases, format, and price. The description is compact, front-loaded, and contains 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 one-parameter, read-only tool with no output schema, the description explains what the tool does, what it returns, where the data comes from, when to use it, the response format, and the cost. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, with the single `ip` parameter already described as 'IPv4 address to check.' The description reinforces IPv4 and reputation checking but does not add meaningful new detail beyond the schema, 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?

Description states a specific action and resource: checking an IPv4 address's threat/abuse reputation and returning a verdict. It also names concrete data sources and outputs, which clearly separates it from generic `ip` lookups and other reputation 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?

Description gives explicit contexts: 'For bot filtering, fraud and firewall automation.' It does not explicitly name alternative tools or say when not to use it, but the use-case framing is clear enough for an agent to route appropriately.

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?

Adds meaningful context beyond annotations: data source provenance (not repackaged public list), return limits, first-seen timestamp, JSON format, and price. Annotations already establish read-only safe operation, so the description need not repeat that. Transparent about what the caller receives.

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 ~50-word description with all essential information front-loaded: feed nature, IP content, provenance, use case, output limit, format, and price. No filler, each clause adds value.

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 list-feed tool with one optional parameter and no output schema, the description covers the main answer: what is returned (IPs, first-seen), volume cap, use case, and cost. Minor gaps are pagination/authentication details, but they are secondary 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 documentation covers the single limit parameter fully (1-500, default 200). The description does not mention the parameter, but it does not need to because the schema already conveys semantics. Baseline of 3 applies due to high 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?

States a specific verb and resource: returns a feed of recent IPs caught probing honeypot paths. Clearly differentiates from a generic IP tool by emphasizing first-party telemetry and bulk list nature, distinguishing it from sibling threat_ip.

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 gives use cases: for blocklists and threat research. Does not mention when not to use or alternative siblings, but the blocklist/research framing strongly implies bulk feed usage rather than single-IP lookup. Clear context but no 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?

Annotations already declare readOnlyHint and non-destructive, and the description adds meaningful behavioral detail: pure computation, JSON return format, end-date exclusivity, weekend/holiday skipping, and inclusion of the holiday list. It also surfaces the monetary price, which is useful 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 tight and front-loaded, opening with the core behavior before adding output format and price. The price note is slightly non-essential for selection, but still relevant since this tool has a cost, so it earns its place.

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

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

For a two-parameter pure computation with no output schema, the description covers input format, date semantics, holiday rules, output content, side-effect profile, and cost. An agent has everything needed to decide whether to call it and what parameters to pass.

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?

While the schema describes start and end only as YYYY-MM-DD strings at 100% coverage, the description adds the range semantics: the tool counts business days between the two dates and excludes the end date. That extra interpretation is valuable for correct invocation, especially in edge cases around endpoint inclusivity.

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

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

The description clearly identifies a specific computation: business days between two dates, with explicit rules (exlusive of end, skipping weekends and US federal holidays) and a concrete result (the holiday list). This distinguishes it from any sibling tool by naming the exact operation and 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 makes the use case obvious: whenever an agent needs US business days between two dates, including the holidays in the range. It does not explicitly discuss alternatives, but none of the sibling tools appear to offer a similar date calculation, so no exclusion is necessary.

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 destructiveHint=false, lowering the behavioral disclosure burden. The description adds meaningful context: exact data sources (OFAC, BIS, State), the fused verdict output with flags, JSON format, and a $0.20 USDC price. No contradictions with annotations.

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

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

The description is one dense, information-rich sentence with no filler. It slightly repeats the title and bundles price alongside 'premium call', so it is efficient but not maximally tight.

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

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

For a tool with no output schema and complex bundled behavior, the description covers the input (name, commodity), the action (screening + Federal Register), the output (verdict with flags, JSON), and price. The optional agency parameter is left to the schema, which is acceptable given full schema coverage.

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 three parameters with descriptions (100% coverage), so the description need not repeat them. It mentions 'counterparty name' and 'commodity/topic' in context, 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?

The description states a specific action ('screens a counterparty name') against a named resource (US Consolidated Screening List) and adds a second action (pulls Federal Register actions). This distinguishes it from siblings like legal_sanctions_screen or legal_reg_watch, which likely cover only one of these areas.

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 clearly frames the tool as 'for import/export compliance' and as a 'bundle' combining two data sources. However, it does not explicitly name alternative tools or exclusion criteria (e.g., when to prefer simple sanctions screening over this premium bundle).

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 destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the schema: it discloses the CLEAR/REVIEW/HOLD decision framing, the specific screening sources, and a fixed price of $0.45 USDC via x402. No contradiction with annotations.

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

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

The description is compact and front-loaded: the bundle identity, outcome types, core checks, and price are conveyed in two sentences with no filler. Every clause adds decision-relevant 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?

For a read-only, non-destructive screening tool with no output schema, the description adequately covers purpose, checks performed, decision outcomes, and cost. The only minor gap is that it does not clarify the alias relationships among the five required parameters, but those are already documented in the input 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 100%, so the baseline is 3. The description adds meaning by connecting parameters to their screening purpose: party/name to US CSL screening, country/destination to embargo checks, and commodity to export-control flagging. This explains why each parameter matters, not just what it is.

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, multi-part purpose: a one-call export/import pre-screen that screens the counterparty against US CSL, checks the destination against US embargo lists, and flags export-controlled commodities, returning CLEAR/REVIEW/HOLD. The 'bundle' label and decision outcomes clearly differentiate it from sibling 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 gives clear context for when to use it: when an export/import clearance pre-screen is needed in a single call. It implies it replaces separate party, sanctions, and commodity checks, though it does not explicitly name sibling alternatives or state when not to use it.

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 indicate read-only, non-destructive behavior. The description adds meaningful behavioral context beyond that: it explicitly says the body is not downloaded, that redirects are followed to the final URL, and that the response is JSON. It also discloses the price, which is useful practical information.

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 information-dense, with two sentences that front-load the purpose and immediately give the key outputs and constraints. Every clause adds value: what is checked, what is returned, what is not downloaded, the intended use, the response format, and the cost.

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 one required parameter and no output schema, the description is complete enough to invoke and interpret: it lists the response fields, specifies JSON as the format, clarifies the non-downloading behavior, and states the cost. No critical behavioral or return-value information is missing for an agent to use this 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 documents the single url parameter with 100% coverage. The description mentions 'http(s) URL' indirectly but adds no deeper semantic detail beyond what the schema provides, so the schema carries the weight and the baseline score of 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?

The description clearly identifies the resource (a URL) and the check being performed, and it enumerates the specific outputs: HTTP status, final URL after redirects, content-type, and key response headers. It is distinguishable from sibling tools like dns_lookup or ip, though it does not explicitly name or contrast itself against a close sibling.

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 phrase 'For link vetting and uptime checks' gives a clear intended use case, so the usage context is implied but not fully explicit. There is no statement about when not to use it or which sibling tool might be better for a different URL-related task.

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 destructiveHint=false, establishing that this is a safe, read-only operation. The description adds valuable behavioral context by specifying the verdict categories, the exact checks performed, and the pricing ($0.05 USDC via x402). It does not contradict the annotations.

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

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

The description is a compact, front-loaded sentence that packs the verdict type, the checks performed, the use case, and the price with no wasted words. Every clause adds useful 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?

For a tool with one required parameter, no output schema, and read-only annotations, this description is complete: it tells the agent what it returns (SAFE/CAUTION/DANGER), what it checks, when to use it, and how much it costs. This is enough for an agent to decide 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?

The input schema has 100% coverage: the 'url' parameter is already described as an 'http(s) URL to check.' The description mostly restates this with 'URL / link safety check' and 'link,' adding no deeper parameter semantics. Since schema coverage is high, 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 identifies the tool as a URL/link safety check bundle that returns a SAFE/CAUTION/DANGER verdict, which is a specific verb+resource. It also lists the checks performed (reachability, redirects, domain age, hosting-IP reputation), making the purpose obvious. However, it does not explicitly distinguish itself from the sibling tool 'url_check', so its differentiation is not fully spelled out.

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 an explicit use case: 'before an agent follows the link.' This tells an agent when the tool is appropriate. It does not mention exclusions or name alternative tools, but the context is clear enough for someone with similar sibling tools to infer its usage.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds behavior beyond that: it charges $0.25 via x402, uses only public federal data, and produces a combined output of specs, recall count, fuel estimate, and a verdict, making side effects and cost transparent. No contradiction with annotations.

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

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

A single dense sentence that front-loads the purpose, then lists inputs, outputs, data source, and pricing in order of importance. Every clause carries information; there is no fluff. The structure aids quick scanning by an agent.

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 read-only tool with no output schema, the description lists all input semantics and the expected output components (decoded specs, recall count, fuel cost, and buy/caution/walk verdict with reasoning), plus cost and data-source context. It is sufficient for an agent to decide to call and interpret the result, though it stops short of detailing response shape or error conditions.

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 three parameters already have descriptions in the schema (17-char VIN, odometer miles, asking price USD), so baseline is 3. The description merely restates them ('Given vin, asking price and miles') without adding units, formats, or constraints beyond the schema. It is adequate but not additive.

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 'Used-car deal check verdict', naming the specific purpose, then enumerates inputs (vin, asking price, miles) and a distinctive deliverable (buy/caution/walk verdict with reasoning). This distinguishes it from sibling vehicle tools like vehicle_report and vehicle_vin, which focus on data rather than an evaluative verdict.

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 clearly states the trigger condition: when you have a VIN, asking price, and miles and want a deal verdict. It also notes the $0.25 cost and public-data basis, which helps an agent decide whether to invoke it. However, it does not explicitly compare against sibling alternatives such as vehicle_report or vehicle_fuel_economy, so exclusions are 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 establish it as read-only and non-destructive. The description adds useful behavioral context: data source (fueleconomy.gov), response format (JSON), and the monetization/payment requirement ($0.003 USDC via x402). This goes beyond what annotations provide, though it does not detail response shape or possible multiple variants.

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 no wasted words. The core purpose leads, followed by essential operational details: data source, output format, and price. Every sentence adds value.

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 three-parameter lookup tool, the description covers the inputs, the return data, the source, the format, and the payment requirement. It does not describe edge cases such as multiple engine/trim variants for the same year/make/model, but the description is reasonably complete overall.

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%, but the individual parameter descriptions are minimal and tautological ('manufacturer', 'model year', 'model name'). The tool description also repeats year/make/model without adding format constraints, normalization rules, or examples. Per the baseline for high schema coverage, a 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 states a specific action and resource: 'Fuel economy lookup (EPA)' using year/make/model, and clearly identifies the output as EPA MPG figures and estimated annual fuel cost. This makes it easy to distinguish from vehicle-related siblings like vehicle_report, vehicle_vin, and vehicle_deal_check.

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 context for when to use the tool: whenever EPA MPG figures or estimated annual fuel cost for a specific year/make/model are needed. It does not explicitly name alternatives or exclusions, but the highly specific lookup purpose makes usage unambiguous.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds valuable behavioral context beyond annotations: it fuses multiple NHTSA & EPA sources, returns JSON, and carries a specific price of $0.25 USDC via x402. This goes beyond simple safety flags and helps an agent anticipate cost and external data dependencies.

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 wasted words. It front-loads the core identity ('Vehicle full report (bundle)') and the 'One call' value proposition, then delivers a scannable component list, output format, and pricing. Every clause 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?

Without an output schema, the description compensates well by naming the report components, the JSON format, and the pricing. It also clarifies the all-in-one nature. Minor gaps remain, such as exact response structure or behavior on invalid VINs, but for a read-only lookup tool with fully documented parameters, the description is largely complete.

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

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

The input schema provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description reinforces that price enables the verdict and that the report includes fuel economy and annual cost, but it does not add new semantic detail beyond the schema, particularly for the optional 'miles' parameter.

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 deliverable ('Vehicle full report (bundle)') and enumerates concrete components: decoded VIN specs, open safety recalls, EPA fuel economy & annual cost, and a buy/caution/walk verdict. It also names the underlying sources (NHTSA & EPA), making it clearly distinguishable from siblings like vehicle_vin, vehicle_fuel_economy, and vehicle_deal_check.

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 through 'bundle' and 'One call', suggesting it is the comprehensive option for vehicle research. However, it never explicitly states when not to use it or names alternatives such as vehicle_vin or vehicle_fuel_economy for narrower lookups. Usage context is implied rather than stated.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds useful behavioral context: the data source (US NHTSA), the JSON response format, the US-market scope, and the per-call price. It does not detail error behavior or response structure, but this is a simple read-only lookup and the annotations carry the safety profile.

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 front-loaded with the core purpose, followed by source, format, and price. Every clause adds distinct information, with 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?

With only one parameter, a well-covered schema, and annotations indicating read-only behavior, the description supplies enough context to invoke the tool correctly. It specifies what it returns (specs and recalls), the format (JSON), the source, and pricing. It does not explain error cases or response details, but for this simple API the missing pieces are minor.

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 describes the vin parameter as a 17-character string with an example. The description adds meaningful domain semantics by limiting the tool to US-market VINs, which constrains the valid input space beyond the schema's generic string 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 states a specific verb ('Decode') and resource ('US-market VIN') and explicitly names the two outputs: full vehicle specs and open safety recalls. The NHTSA reference distinguishes it from sibling vehicle tools like vehicle_fuel_economy and vehicle_deal_check.

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 usage when a US-market VIN needs decoding and recall lookup, and it notes the NHTSA source and price. However, it does not explicitly contrast this tool with siblings like vehicle_report or vehicle_deal_check, leaving the agent to infer when this one is preferred.

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 destructiveHint. The description adds useful behavioral context beyond annotations: National Weather Service as source, JSON output format, pricing/cost, and the specific alert fields returned. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core purpose, then efficiently adds scope, source, output fields, format, and price. Every clause contributes useful information with no filler.

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

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

For a simple read-only lookup, the description is mostly complete: it states inputs, output fields, source, format, and cost. The main gap is that 'state or coordinate' could mislead an agent into omitting the required state field, and there is no output schema, though the listed fields mitigate that concern.

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 all three parameters. The description restates the state-or-coordinate usage mode but adds no new format or constraint details. The phrase 'state or coordinate' is also slightly ambiguous against the schema's required ['state'], though this likely originates from the schema's own 'or use lat+lon' note.

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 identifies the tool as retrieving active NWS watches/warnings/advisories for a US state or coordinate. The alert-specific nouns and 'Active' scope distinguish it from sibling weather tools like weather_current, weather_forecast, and weather_metar without needing to open 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?

Provides clear context: use it for active US alerts by state or coordinate. However, it does not explicitly state when not to use it or name alternatives such as weather_travel_risk, so the usage guidance is clear but lacks 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: data comes from the National Weather Service, returns JSON, uses the nearest weather station, is limited to US coordinates, and has a stated price. This goes beyond the annotations and helps the agent understand what to expect.

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 front-loaded: it opens with the tool's purpose, then lists the specific data fields, source, format, and cost. Every sentence adds information without fluff. The one-sentence structure is dense but easily parseable.

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 only two simple string parameters and no output schema, the description is largely complete: it states the location scope, the data fields returned, the source, and the output format (JSON). It does not specify units (e.g., Fahrenheit vs Celsius) or exact JSON structure, but these are not critical for invoking the tool. Overall, it gives an agent enough to call it correctly and interpret the result.

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%: both lat and lon are described as 'latitude' and 'longitude', so the schema carries the basic meaning. The description adds a small but meaningful constraint that the coordinates must be in the US ('near a US coordinate'), but it does not provide format details such as decimal degrees or range validation. This is a marginal improvement over the schema, so a baseline score 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 identifies what the tool does: 'Latest observed conditions near a US coordinate' with explicit fields (temperature, wind, humidity, visibility, pressure). This distinguishes it from sibling weather tools like weather_forecast and weather_hourly by focusing on current observed conditions. The verb 'current' and resource 'US current conditions' are specific and unambiguous.

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

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

The description gives clear context: it is for current, observed conditions rather than forecasts or alerts, which is reinforced by the title. It does not explicitly name alternatives or state exclusions, but the 'current conditions' phrasing makes the appropriate usage obvious among the weather sibling tools. It could be improved by explicitly saying 'for forecasts use weather_forecast,' but that is not necessary given the clarity.

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 establish readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: the source (NWS), output fields, JSON format, and the $0.003 USDC price. No auth or rate-limit details are provided, but the read-only nature and simple call make this acceptable.

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 compact and front-loaded: purpose, scope, output fields, source, format, and price are all conveyed in one efficient sentence plus short fragments. There is no filler or repetition of schema details.

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 read-only two-parameter tool with no output schema, the description provides enough to understand what will be returned and what it costs. Units (Fahrenheit/Celsius) are not specified, but the listed output fields and NWS source give sufficient context for most callers.

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

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

Input schema covers both required parameters (lat, lon) with explanatory examples, so schema coverage is 100%. The description adds only 'any US coordinate' as extra context, which is helpful but does not substantially extend parameter meaning 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?

Description clearly identifies the tool as a 7-day NWS forecast for any US coordinate, listing key output fields (temperature, wind, precipitation chance, narrative). It is easily distinguishable from siblings like weather_current and weather_hourly by the '7-day forecast' scope, though it does not explicitly name those alternatives.

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 '7-day forecast' phrasing implies use for forecasting rather than current conditions or alerts, and 'US coordinate' defines geographic scope. However, there is no explicit statement of when not to use this tool or which sibling should be chosen for current weather, hourly data, alerts, or other conditions.

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