Scout Packs

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the non-obvious traits that payment is x402/USDC and that the agent's own wallet executes the payment while the tool only returns instructions. However, it omits irreversibility, cost magnitude, auth requirements, and failure behavior for a financial transaction, leaving meaningful gaps.

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

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

Front-loaded with the core action and resource, followed by the payment mechanics and pack values. Information density is high with little waste, though the two sentences about the payment flow could be tightened slightly.

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

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

An output schema exists, so return values need not be explained, and the description correctly focuses on inputs and the buying flow. For a 1-parameter payment tool it covers what an agent needs to initiate the call, with only the cost/auth edge cases left unspecified.

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 0% and there is no enum on 'pack', but the description compensates by enumerating the allowed values ('25', '50', or '100'), effectively supplying the missing enum semantics. It adds no other parameter detail, but for a single param this covers the essential 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?

States a specific verb+resource: 'buy a Scout Pack of verified B2B leads', with a parenthetical clarifying what the leads are (people search results with verified business emails). This is clearly distinguishable from list_packs/packsize, which the description implicitly frames as browsing rather than buying. No explicit sibling callout, so 4 rather than 5.

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

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

It implies usage ('Get the exact x402 payment requirements and step-by-step buying flow') and signals this is the purchase step, but never states when to choose buy_pack over list_packs or packsize, nor any prerequisite such as needing to list packs first. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the behavioral burden and does it well: it discloses cost ($0.02 USDC per call) and the payment mechanic (returns x402 payment requirements; the wallet executes payment). That payment/cost detail is genuinely useful and not captured by any structured field. It does not mention rate limits or failure modes, keeping it short of a 5.

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

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

Front-loaded with purpose, then cost, then return/payment behavior, then a concrete example. Every sentence earns its place with no filler.

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

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

An output schema exists, so return-field explanation is not required, and the description still lists the extraction surface plus cost and payment flow. It is nearly complete for a single-parameter paid tool, missing only edge/error behavior.

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 0% and there is only one parameter, so the description must supply format meaning. The example contact_page(domain="acme.com") usefully shows the parameter is a bare domain string, but it doesn't clarify whether paths, schemes, or subdomains are accepted.

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

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

States a precise verb+resource ('Extract a company's published contact surface from its own public website') and enumerates the concrete outputs (emails role vs personal, phones, contact-form presence, address, social links). An agent can immediately distinguish this from siblings like email_pattern, lookup_lead, or dns.

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 scope ('from its own public website') is clear, but there is no explicit when-to-use or when-not guidance relative to siblings such as lookup_lead or email_pattern. Usage is implied by what it extracts 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?

With no annotations, the description carries the full burden and does well on the operationally critical parts: it discloses the per-call price ($0.03 USDC) and the x402 payment handshake where the agent's wallet settles the charge. It does not spell out rate limits, auth requirements, or that the operation is read-only/non-mutating, leaving a modest gap.

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

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

Dense but front-loaded: capability list first, then pricing/payment, then concrete invocation examples. Every line carries information, though the opening run-on of checks is slightly crammed.

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

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

An output schema exists so return values need not be detailed, and the description still summarizes what the result contains (checks plus a 0-100 score and verdict). Input forms and the payment flow are covered; only edge behavior (errors, rate limits, invalid targets) is unaddressed.

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 single 'target' parameter has 0% schema description coverage, so the description must compensate — and it does, showing that target accepts either a full email (jane@acme.com) or a domain (acme.com). This is the key ambiguity an agent would otherwise hit, though no format/validation details beyond the examples are given.

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 ('Email verification') and enumerates concrete outputs (MX/SPF/DMARC checks, disposable-domain and role-account detection, bounce-risk score 0-100 with a verdict), which naturally separates it from raw-DNS siblings like dns or domain_intel. It never explicitly names a sibling it is not, so it falls short of full 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 examples show two invocation shapes (email address vs bare domain), implying usage, but there is no statement of when to prefer this tool over dns, domain_intel, or lookup_lead, and no exclusions or prerequisites beyond the payment note. Usage is inferable rather than spelled out.

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

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

With no annotations, the description carries the full burden and does well: it discloses the transport (DNS-over-HTTPS), the per-call cost ($0.01 USDC), and the non-obvious payment flow (returns x402 payment requirements that the agent's wallet settles). It does not state read-only semantics, rate limits, or failure modes, but the pricing/payment disclosure is substantial 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?

Four tight sentences, each earning its place: purpose and record types first, then cost, then the payment mechanic, then a concrete example. No filler and the most important information is front-loaded.

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

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

For a one-parameter lookup with an output schema already covering return values, the description covers purpose, cost, and payment behavior adequately. The only notable omissions are read-only/rate-limit expectations and edge-case behavior on invalid domains.

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 0% for the single required 'domain' parameter, so the description has to compensate; it does partially by giving dns(domain="acme.com"), which shows the expected bare-domain format with no scheme or subdomain noise. It adds limited semantic detail beyond the example (e.g., whether IDN or URL inputs are accepted).

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 (Dump) and resource (a domain's DNS records) and enumerates the record types and the SPF signal it returns, so the agent knows exactly what it gets. It does not name or contrast itself with any sibling tool (ssl_check, headers, tech_stack), so it falls short of the 5 bar for explicit 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?

Usage is only implied: the DNS-record purpose makes it obvious when the tool is relevant, and the worked example shows invocation, but there is no explicit when-to-use, when-not, or pointer to alternatives such as ssl_check or tech_stack.

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

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

With no annotations, the description carries the full burden and does well: it discloses a concrete cost ($0.02 USDC per call) and the x402 payment handshake (the tool returns payment requirements and the agent's wallet executes the payment). It does not mention rate limits, caching, or failure behavior, and return payload detail is left to the output 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?

Four tightly packed lines with the core purpose front-loaded, followed by data sources, price, payment mechanics, and an example. Slight redundancy between the opening 'Company enrichment from domain' and the 'lead data' clause, but nothing is wasted.

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

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

An output schema exists, so return-value description is unnecessary; the description covers purpose, data sources, cost, and the payment flow an agent must handle. The main remaining gap is the absence of routing guidance relative to the many domain/lead siblings.

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 0% for the single required parameter, but the description supplies a concrete worked example, domain_intel(domain="acme.com"), which removes ambiguity about the expected value format. It does not clarify edge cases such as subdomains, URLs, or IDN domains, so it falls short of full compensation.

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

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

States a specific verb+resource ('Company enrichment from domain') and enumerates the exact data returned (RDAP registrar and creation/expiry dates plus DNS infrastructure signals). It is clear what the tool does, though it does not explicitly contrast itself with close siblings such as dns, dossier, or lookup_lead.

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 enrichment framing implies the use case (lead/company data from a bare domain), but there is no explicit when-to-use guidance and no statement about when to prefer sibling tools like dns or lookup_lead. The example shows invocation format, not selection criteria.

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

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

With no annotations, the description carries the full burden and does well: it discloses per-call cost ($0.05 USDC), the payment flow (returns x402 payment requirements, wallet executes payment), and the response shape (single fused response with an aggregated signals list). It omits rate limits, failure behavior, and per-signal error handling, keeping it short of a 5.

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

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

Front-loaded with the purpose, then signal list, then pricing/payment, then an example — a sensible ordering with little waste. Slightly dense for the number of ideas packed into a few lines, but every sentence carries 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?

An output schema exists, so return-value explanation is unnecessary, and the payment/authorship mechanics are covered. The remaining gap is routing guidance against the many overlapping single-purpose siblings, which an agent calling this composite tool would benefit from.

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 0% and the single 'domain' parameter is undocumented in the schema, but the description implies its meaning ('enrichment from domain') and gives a concrete call example: dossier(domain="acme.com"). That compensates partially for the gap without adding format/syntax detail.

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

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

States a specific verb+resource ('Company enrichment from domain — composite domain dossier') and enumerates exactly which signal families it fuses (RDAP, DNS, tech stack, email patterns/MX, SSL/TLS). The 'fused into a single response' framing distinguishes it from the single-signal siblings like dns, ssl_check, and tech_stack.

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 only implied: the composite/aggregated framing suggests 'use this when you want all signals at once', but no sibling is named and there is no explicit when-not guidance (e.g., 'use dns instead if you only need DNS records'). The example call is helpful but not a routing rule.

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

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

No annotations, so the description carries the full burden, and it discloses key behavioral facts: the $0.01 USDC per-call cost, that it returns x402 payment requirements, and that the caller's wallet must execute the payment. That payment/auth flow is significant context. It omits rate limits and what a failed MX check implies, keeping it below 5.

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

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

Front-loads purpose, then output contents, then pricing/payment, then a concrete example — a logical progression with little filler. Slightly dense but each sentence (including the payment note) 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?

An output schema exists, so return-value explanation is not required, and the description instead fills the more important gap of the x402 payment flow. The one remaining gap is that it never says what the tool returns once payment succeeds, but the output schema and payment note largely cover the agent's needs.

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

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

Schema description coverage is 0% for the single required 'domain' parameter, so the description must compensate. The worked example email_pattern(domain="acme.com") does clarify that the value is a bare domain rather than a URL or email address, which is useful, but nothing is said about subdomains or edge-case formats.

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

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

Names a specific verb+resource: generating likely corporate email address patterns for a domain plus MX verification. The parenthetical examples (first.last@, first@, flast@) make the output concrete. It does not explicitly distinguish itself from close siblings like deliverability or lookup_lead, which also touch email/lead data, so it stops short of a 5.

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

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

The description implies the use case (lead enrichment / Apollo-style verification) but never states when to choose this over deliverability, contact_page, or lookup_lead, nor any prerequisites or exclusions. Usage is left to inference from the phrasing.

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

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

With no annotations, the description carries the full burden and does disclose the significant non-obvious behavior: $0.01 USDC per call, x402 payment requirements returned, and the agent's wallet executing the payment. It omits auth scope and rate-limit behavior, but the paid-call flow is the key surprise an agent must know.

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 short, front-loaded lines: purpose with output shape first, then cost, then a concrete invocation example. Every sentence earns its place with no filler.

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

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

An output schema exists so return values need not be detailed, and the description still summarizes the score/grade result. The payment flow is covered; only auth context and failure modes are missing.

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

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

Schema description coverage is 0%, but the description compensates with an explicit call example headers(domain="acme.com") that shows the expected format (bare domain, no scheme). With only one self-explanatory parameter this is nearly sufficient, though the required/optional nature is left to the schema.

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

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

States a specific verb (audit) and resource (HTTP security headers: HSTS, CSP, X-Frame-Options), plus the concrete output shape (0-100 score, A-F grade). This clearly separates it from siblings like ssl_check, dns, and tech_stack without opening any schema.

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

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

There is no guidance on when to reach for this tool versus ssl_check or other siblings, and no preconditions stated beyond the payment note. The example implies a single-domain use case but the description never routes the agent between alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It adds a little context (the operation is free, the sample is redacted), but says nothing about read-only nature, pagination, or auth requirements, which is thin for a listing endpoint.

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, the second being a fragment describing the lead contents. It is short but the phrasing is promotional and not front-loaded around the tool's function.

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

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

An output schema exists, so return-value exposition is not required, and the description does indicate what the packs contain. However, with no annotations and no routing information relative to buy_pack or lookup_lead, it stops short of being 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 tool takes zero parameters, so per the baseline a 4 applies. There are no arguments for the description to elaborate on.

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 conveys what the tool surfaces — B2B lead packs with sizes, prices, and a redacted sample — but it reads as marketing copy rather than stating the action plainly (it never says it returns/lists available packs). It also never differentiates itself from the sibling buy_pack, leaving the browse-vs-purchase distinction to inference.

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?

There is no explicit when-to-use guidance and no mention of the alternatives buy_pack or lookup_lead. The word "Free" faintly implies this is a no-cost browsing step before purchase, but that is left for the agent to infer.

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

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

With no annotations, the description carries the full burden and does well: it discloses the $0.01 USDC cost, that the response is x402 payment requirements rather than the lead itself, and that the caller's wallet must execute the payment. That is non-obvious, high-value behavioral context. It stops short of describing failure modes (e.g. no email found, invalid domain) or whether the payment is charged on a miss.

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?

Roughly four short sentences, front-loaded with the resource and the payload/cost, and the examples sit at the end where they are easy to copy. The opening 'people search: company enrichment' fragment is the only slightly noisy bit and could be tightened.

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 paid lookup with an output schema, the description covers the essential non-schema facts: what is returned (verified email + source URL), the cost, and the payment handshake. Return-value detail is correctly left to the output schema. Missing only edge-case behavior for lookups that yield no email.

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 0% for the single 'query' parameter, so the description must compensate. The two worked examples (query="Acme Corp", query="acme.com") do communicate that both a company name and a domain are accepted, which is the key semantic the schema omits. It does not say whether a person's name or email is also valid, leaving a small gap.

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 concrete verb+resource (lookup/enrich a lead, returning a verified business email and source URL), and the two example queries make the resource unambiguous. The lead-in phrase 'people search: company enrichment by company name or domain' slightly muddles whether it is people or company search, but the rest of the sentence resolves it. Siblings are in different domains (dns, ssl_check, headers), so no direct disambiguation is needed.

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

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

No statement of when to use this versus alternatives, and no prerequisites beyond the implicit query. The two examples (company name vs domain) hint at acceptable input forms but do not constitute usage guidance. Nothing tells the agent when this tool is the wrong choice.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses the per-call cost ($0.01 USDC), the x402 payment flow (returns payment requirements, wallet executes payment), and that detection is derived from MX records. It lacks detail on failure modes or rate limits, but the payment/auth behavior — the most consequential trait here — is explicit.

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 tight sentences, front-loaded with what is detected and followed by cost/payment and an example. No filler, though the provider/gateway name lists are slightly long.

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

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

An output schema exists so return shape needn't be described, and the description still covers the non-obvious part — the x402 payment mechanics. For a one-parameter lookup tool this is close to complete; only failure/error behavior is unaddressed.

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 0% (the single `domain` parameter has no description), so the description must compensate. The worked example `mail_provider(domain="acme.com")` does convey format and usage, though it doesn't state edge cases (subdomains, bare domain vs FQDN).

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 (identify a domain's email provider) and enumerates the concrete outputs: mailbox host (Google Workspace, Microsoft 365, Zoho, Proton) and gateway detection (Mimecast, Proofpoint, Barracuda) from MX records. That specificity makes it easy to distinguish from the generic `dns` sibling without opening a 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?

The implied use case is obvious from the description (look up who hosts email for a domain), but there is no explicit when-to-use/when-not guidance or routing to alternatives such as `dns` for non-MX records. Adequate but leaves the agent to infer the boundary.

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

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

With no annotations, the description carries the full burden and does well: it discloses the $0.02 USDC cost, that returns are x402 payment requirements, and that the agent's wallet executes payment. This is critical behavioral context beyond structured fields. It stops short of describing what happens if payment fails or any rate limits.

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

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

Front-loaded purpose, then cost/payment behavior, then a concrete example. Every sentence earns its place and the example format is efficient.

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 2-param tool with an output schema present, the description covers purpose, cost, payment flow, and an example. It doesn't need to explain return values (output schema exists) and is nearly complete, though it could mention error/edge-case behavior for a payment-gated 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 0%, so the description must compensate. It clarifies that title is the product title to parse and price is optional package price, and the example shows expected formats (title="... 2lb", price="$29.99"). This adds real meaning but doesn't fully document format expectations or edge cases for both parameters.

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 (parse/resolve) and resource (product title into pack count, unit size, unit price). 'Pack-size resolver' plus the enumerated outputs makes the purpose unambiguous and distinct from siblings like list_packs or buy_pack.

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 it's used (resolving pack size from a title) and the example clarifies the calling context. However, it gives no explicit when-to-use vs alternatives guidance and doesn't clarify the relationship to sibling tools like list_packs or buy_pack, so usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the two hardest-to-guess traits: the $0.01 USDC charge per call and the x402 payment flow where the agent's wallet executes payment. It does not mention rate limits, failure modes, or latency, keeping it short of a 5.

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

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

Three sentences plus an example, front-loaded with the capability, then cost, then payment mechanics, then a concrete call. Every sentence earns its place with no filler.

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

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

An output schema exists so return values need not be described, and the description covers capability, cost, and payment path. It stops just short of complete because it never says what error/paid-required responses the agent should expect or how to retry after payment.

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

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

Schema description coverage is 0%, so the description must compensate, and the embedded example repo_health(repo="octocat/hello-world") is the only thing that reveals the expected owner/name format. That is genuinely additive, though it never states whether the value is required or what format variants are accepted.

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 (Check) and resource (a public GitHub repo's health) and enumerates exactly what is measured: stars, forks, open issues, license, archive status, 90-day commit velocity. No sibling tool overlaps this domain, so an agent can select it unambiguously.

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 word 'public' implicitly excludes private repos, and the pricing line tells the agent this call has a cost, which is decision-relevant when choosing whether to invoke it. It does not name alternatives or explicitly state when not to use it, but for a unique-domain tool that gap is small.

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

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

With no annotations, the description carries the full burden and does well on the non-obvious parts: it discloses the $0.01 USDC cost, explains that the call returns x402 payment requirements, and that the agent's wallet executes the payment. It omits failure/error behavior and any rate or auth constraints, but the payment mechanics are the critical disclosure for this 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?

Front-loaded with the purpose, then outputs, then cost/payment, then an example — every line earns its place and nothing is padded. The example is short and directly actionable.

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

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

An output schema exists, so enumerating return fields is slightly redundant but harmless, and the description correctly spends its budget on what the schema cannot convey: the paid x402 flow and per-call price. Missing only error/quota behavior, which is minor for a read-only domain check.

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?

There is a single parameter with 0% schema description coverage, and the description compensates with a concrete call example (ssl_check(domain="acme.com")) that fixes the expected format. It does not define edge cases (bare domain vs URL vs subdomain), but the example adds real value over the bare string schema.

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

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

States a specific verb+resource ('SSL/TLS certificate check') plus the exact payload (issuer, expiry, days remaining, TLS version, risk flags), so the agent knows precisely what this returns. It does not, however, contrast itself with domain-adjacent siblings such as dns, headers, or domain_intel, leaving the boundary to inference.

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 only implied through the 'lead data' framing and the risk-flag list — there is no explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. An agent can infer it is for certificate inspection, but must guess when that beats dns or domain_intel.

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

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

With no annotations, the description carries the full burden and does well: it discloses the per-call cost ($0.02 USDC), the passive data source (CT logs, implying no active scanning), and the two-step payment flow where the tool returns x402 requirements and the agent's wallet settles them. It omits wallet prerequisites, rate limits, and failure modes, keeping it short of a 5.

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: purpose, classification categories, cost, payment semantics, and a concrete call example. The most decision-relevant information (what it maps) is front-loaded 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?

An output schema exists, so return-value detail is not needed, yet the description still flags the unusual x402 payment-requirement return, which is essential for correct invocation. Only the input-format ambiguity and missing operational limits keep it below complete.

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

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

Schema coverage is 0% for the single 'domain' parameter, so the description must compensate. The inline example subdomains(domain="acme.com") clarifies the expected value format, but it never states whether a subdomain, URL scheme, or apex-only input is accepted.

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 ('Map') and resource ('a domain's live subdomain footprint'), names the data source (Certificate Transparency logs) and the output taxonomy, so an agent can distinguish this from sibling tools like dns, ssl_check, or headers without opening a 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?

The description never says when to reach for this tool versus alternatives such as dns or tech_stack, nor when it is inappropriate (e.g. apex resolution vs subdomain discovery). It supplies payment mechanics but no selection guidance at all.

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

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

With no annotations, the description carries the full burden and does disclose two critical behaviors: cost ($0.01 USDC per call) and the payment flow (returns x402 payment requirements, wallet executes the payment). It does not mention rate limits, error behavior, or failure modes for unreachable domains, so it is strong but not exhaustive.

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

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

Front-loads the core purpose, then detection method, pricing, payment mechanics, and an example — a logical order. The opening 'Company enrichment from domain — lead data:' framing is slightly redundant preamble, but the rest of the text is dense and 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?

An output schema exists, so return values need not be restated, and the description already previews the shape (per-technology confidence and evidence). Cost and payment flow are covered. What remains thin is guidance on the tool's boundaries versus its many sibling enrichment tools.

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

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

Schema coverage is 0% and only one parameter exists, so the schema alone gives no guidance. The example 'tech_stack(domain="acme.com")' clarifies that the parameter is a bare registrable domain (no protocol, path, or URL), which is meaningful semantic information beyond the schema's bare 'string' type.

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 ('Identify the web technologies powering a domain') and enumerates the detected categories (CMS, frameworks, analytics, CDNs) plus the data sources (HTTP headers, page markup). This clearly distinguishes it from sibling tools like headers, dns, and domain_intel.

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

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

The description frames the tool as 'lead data: tech-stack detection' and provides a concrete example call, which implies when it fits, but it never states when to prefer it over siblings such as headers or domain_intel, nor any exclusions. Usage is inferred rather than specified.

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