draconic21 Daily Agent Signal + x402 Data Tools

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), it discloses genuinely useful behavior: US-only coverage, 30-minute per-query caching, the x402/Base payment rail, that the caller's own wallet pays, and that the server never holds a wallet or pays on the agent's behalf. These are non-obvious operational traits an agent must know before invoking.

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

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

The pricing/purpose hook is front-loaded and each sentence is substantive. There is mild redundancy — the price is stated twice and the 'server never pays on your behalf' point is made in both the intro and the payment_header description. Still reasonably tight for the amount of payment detail being conveyed.

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 steps in to describe return values (matched coordinates for forward, containing state/county/tract/block/CBSA for reverse, plus a count/items[] alias). Combined with the fully spelled-out payment handshake, an agent has everything needed to call 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 the schema already documents q-as-alias, lat/lon pairing, address exclusivity, and the payment_header contract. The description largely restates these, though it does add the return-shape note about a count/items[] alias modeled on a comparable's field names. Baseline 3 is appropriate when the schema carries the parameter burden.

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 pair — forward and reverse U.S. geocoding — and names its upstream data source (Census Bureau Geocoder). It clearly enumerates the two modes via the address vs. lat/lon inputs. It does not, however, differentiate itself from the adjacent address_geocode_preview sibling, leaving the paid/preview split to be inferred from the name.

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 explicit procedural guidance: call with no payment_header first to get the challenge, then re-call with the signed header and the SAME business arguments. It also states the mutual exclusivity of the address and lat/lon input modes. It never says when to prefer this paid tool over the _preview alternative, so the when-not half is missing.

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 readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: it is free, requires no wallet, no payment, and no arguments, which tells the agent it can be invoked safely and cheaply as a probe.

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 with the '[FREE]' qualifier front-loaded so the cost implication lands first. The nested parenthetical restating the paid tool's title is slightly redundant and adds length without much 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 zero-parameter preview tool with no output schema, the description covers what an agent needs: it is free, argumentless, and returns a sample of the paid tool's output shape. The only omission is that it does not describe the sample contents, which is acceptable since the tool's purpose is precisely to reveal them.

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 are zero parameters and schema coverage is 100%, so the baseline is 4. The description reinforces this with 'no arguments needed', which correctly sets the expectation that the tool takes no input.

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 this returns a sample response for address_geocode so the agent can inspect the shape before paying, which is a specific and non-tautological purpose. It implicitly distinguishes itself from the paid sibling address_geocode via the '[FREE]' tag and the preview framing, though it never names the paid tool as the alternative explicitly.

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 a clear condition for use: call it to see the response shape before spending 0.008 USDC. It does not spell out when NOT to use it (e.g. when real geocoding data is actually needed), but the preview-vs-paid context is easy to infer from the sibling name address_geocode.

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/idempotent/openWorld, so the safety profile is covered — and the description goes well beyond it by disclosing the paid tier, the 0.01 USDC-on-Base price via x402, that the caller's own wallet pays, and that the server never holds a wallet or pays on the caller's behalf. That is exactly the kind of behavioral context annotations cannot express.

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 purpose and price tag, then the merge/scope claim, then the input rule, then payment mechanics. Dense but each sentence carries required information. Slightly long, with the competitor-comparison clause being the only near-disposable sentence.

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

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

For a paid, nested-payment-header, no-output-schema lookup tool, the description covers everything an agent needs: accepted identifier types, ambiguity handling, the full x402 payment handshake, and the shape of the returned record. No output schema exists, yet the return fields are summarized.

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 each parameter already documents its own mutual exclusivity, so the schema does the heavy lifting. The description's restatement of the 'exactly one of' rule and the q-as-name-alias note add only marginal value beyond the structured fields. 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?

States a specific verb+resource — a normalized company-identity record — and enumerates the returned fields (legal name, LEI, CIK, tickers/exchanges, jurisdiction, status, parent). It also scopes the data sources (SEC EDGAR + GLEIF LEI) and contrasts scope against a narrower alternative, so an agent can tell it apart from the edgar_* and company_lookup_preview siblings 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?

Explicitly states the input constraint ('Exactly one of name/q/ticker/lei/cik required'), the fallback behavior for ambiguity ('ambiguous name queries return top_matches instead of guessing'), and the exact payment call sequence (call with no payment_header to get the challenge, then re-call with the same business args plus the signed header). Nothing about when/how to invoke 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 cover readOnly/idempotent/non-destructive, and the description adds genuinely new operational context: it is free, requires no wallet, no payment, and no arguments. That is real behavioral value beyond the structured fields.

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

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

A single front-loaded sentence leads with '[FREE]' and packs purpose, cost, and the no-argument fact without padding. 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 zero-parameter preview tool with no output schema, the description tells the agent what it gets (a sample response showing the shape) and that no setup is needed. Adequate, though it could say more about what the sample contains.

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, which is the baseline-4 case, and the description reinforces this with 'no arguments needed.' Nothing further is required.

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 concrete resource it mirrors ('company_lookup (Company identity lookup (SEC EDGAR + GLEIF LEI merge))') and states it returns a sample response, so an agent can distinguish it from the paid sibling. It is clear but relies on restating the title rather than adding new distinguishing detail.

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 an explicit condition for use: 'so you can see the shape before paying 0.01 USDC,' which routes the agent to this tool first and the paid company_lookup afterwards. It stops short of an explicit when-not statement, but the intent is 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?

Well beyond the readOnly/idempotent/openWorld annotations, it discloses the cost (0.001 USDC on Base), that payment is made by the calling agent's own wallet and never by the server, the data provenance (own GDELT news_search client plus Hacker News), and an honesty guarantee that whyItMatters/match are null rather than fabricated sentiment.

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 price and paid-feed identity are front-loaded, which is good, but the body is an overstuffed run-on full of parenthetical asides (the 'matching its $0.001 price exactly'/'field-for-field' compatibility claims add bulk without decision 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?

There is no output schema, so the description carries the return-shape burden and does so: it names headlines[] with title/url/source/publishedAt and the {status, data, meta} nesting, plus the optional limit and the full payment round-trip. An agent has everything needed to call 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 (limit, payment_header) are already fully documented in the schema, including the base64 payload shape. The description largely restates the schema ('Optional limit (1-30, default 20)'), so with the schema carrying the load a baseline 3 is correct.

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 resource — a fixed, no-required-params crypto headline feed returning headlines with title/url/source/publishedAt — so an agent can tell what it returns. It does not name the obviously adjacent sibling crypto_news_preview (the sibling list pairs every paid tool with a *_preview variant), so the differentiation burden falls on the reader.

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 explicit invocation flow: call first with no payment_header to get the x402 challenge for free, then re-call with the same business arguments plus the signed PAYMENT-SIGNATURE header. It does not say when to prefer this over crypto_news_preview or news_search, but the payment mechanics are unusually well specified.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations: no wallet, no payment, no arguments, and that the output is a sample rather than live data. It stops short of describing the payload shape itself.

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, front-loaded with the [FREE] marker and the key constraint (no wallet, no payment, no arguments). Nothing is wasted and the most decision-relevant fact leads.

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

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

For a zero-param preview with rich annotations and no output schema, the description covers cost, authentication, and the sample nature adequately. It could say what the preview actually contains (headlines) to be fully self-sufficient, but the title supplies that.

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

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

The schema has zero parameters, so per the baseline this dimension is rated 4. The description reinforces this by stating 'no arguments needed', which is consistent with the empty 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 the parent tool (crypto_news) and states this is a free sample of its response, so an agent can tell it apart from the paid sibling. It is clear enough about what it returns, though the actual content (headline feed) is only conveyed via the title rather than spelled out in the body.

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 a clear condition for use: 'see the shape before paying 0.001 USDC', implicitly routing the agent to crypto_news for the real data. It does not explicitly state when not to use it, but the pricing/model context makes the selection obvious.

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

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

Adds substantial context beyond the annotations (readOnly/openWorld/idempotent/non-destructive): the exact data sources (IANA RDAP bootstrap, TLD registry RDAP, own resolver, no third-party DoH relay), a 30-minute cache, that raw is honestly null, and the full payment model where the calling wallet pays and the server never holds a wallet. These are non-obvious traits an agent needs to call it correctly.

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 well front-loaded: the paid marker and one-call value proposition come first, followed by data sources and payment mechanics. Some redundancy — the $0.012 USDC / x402 payment terms appear both at the start and the end — but nearly every sentence carries real 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?

Despite there being no output schema, the description explains return contents (RDAP fields, email-auth records, posture summary, additive aliases, null raw), sources, caching, and the payment precondition. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both parameters (domain and the nested payment_header) are already fully documented in the schema, including the two-step payment handshake. The description's parameter-relevant content merely restates the payment flow, so the baseline 3 is appropriate when the schema does 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?

States a specific verb and resource ('Domain identity & trust posture in one call') and enumerates exactly what is returned: RDAP registration data, live DNS email-auth (MX/SPF/DMARC/NS), and a heuristic posture summary. An agent can clearly separate this from siblings like domain_intel_preview or email_validate 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 gives a concrete paid-workflow instruction ('Call with no payment_header first to receive the payment requirements... call this same tool again with the SAME business arguments'), which is useful usage guidance. However, it never says when to prefer this over the sibling preview tool or email_validate, so alternative-selection guidance is absent.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds material context beyond the structured fields: it is free, requires no wallet or payment, and takes no arguments. It does not describe pagination, rate limits, or exactly what the sample contains.

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 efficient sentence front-loads the [FREE] tag and preview nature, then states the payment/argument facts. Every clause earns its place and nothing is repeated.

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

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

For a zero-arg, annotation-covered preview with no output schema, the description is nearly complete: it establishes cost, prerequisites (none), and purpose. It could say more about what the returned sample payload contains, but 'see the shape' adequately sets expectations for a preview 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?

There are zero parameters and schema coverage is complete, so the baseline is 4. The description reinforces this with 'no arguments needed,' adding no contradictory or missing 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 clearly states this is a free sample/preview response for domain_intel, and the title/description identify the underlying resource (domain identity & trust posture via RDAP + DNS email-auth). It distinguishes itself from the paid sibling domain_intel by being a no-cost shape preview. It stops short of describing what the preview content actually contains, but the preview-vs-paid distinction is unambiguous.

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

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

It gives a clear reason to call it ('so you can see the shape before paying 0.012 USDC') and explicitly notes 'no wallet, no payment, no arguments needed.' The implied when-to-use (evaluate before paying for domain_intel) is present, though it never names domain_intel as the alternative tool explicitly or states 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 cover read-only/idempotent/open-world, and the description adds substantial non-obvious behavior: the agent's own wallet pays, this server never holds a wallet or pays on the user's behalf, and the first call is free to retrieve the payment challenge. This is exactly the kind of payment-flow disclosure annotations cannot express.

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 price and purpose, and the payment steps follow logically. Slightly redundant in restating the $0.03/USDC/x402 payment detail in two places, which costs it a point.

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

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

No output schema exists, but the description makes clear the return is the union of filings + company facts for one company, so an agent knows what to expect. With annotations covering safety and the schema covering inputs, the only residual gap is explicit return-shape detail, which is minor given the explicitly named constituent 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 100%, so the schema already documents all 8 parameters including the nested payment_header. The description adds the nuance that business arguments must be reused identically across the two calls, but no format or constraint detail beyond the 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?

States a specific verb+resource: it bundles edgar_filings + edgar_company_facts for one company in a single paid call, and even quantifies the cost advantage over buying both ($0.04 vs $0.03). An agent can identify the constituents and the combined resource 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?

Gives clear operational context: call with no payment_header first to get the x402 challenge, then re-call with the same business arguments plus the signed header. It implies use-when-you-need-both via the 'cheaper than buying both separately' framing, but never explicitly routes to edgar_filings or edgar_company_facts for single-need 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new operational context: free, no wallet, no payment, and no arguments required — useful for cost/auth decisions not present in 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?

A single efficient sentence with the [FREE] qualifier front-loaded and no redundant filler; 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 zero-param preview with no output schema, the description adequately conveys that the return is a sample of the edgar_bundle shape (filings + company facts). It could say slightly more about what the sample contains, but nothing essential for correct invocation 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?

With zero parameters the baseline is 4. The description confirms 'no arguments needed', which matches the empty schema and removes any doubt about supplying inputs.

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 noun (a sample response for edgar_bundle) and its resource (SEC EDGAR filings + company facts), and explicitly frames it as a preview so an agent can distinguish it from the paid edgar_bundle 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?

It clearly states the condition for use — 'see the shape before paying 0.03 USDC' — and that no payment is required, which effectively routes the agent to edgar_bundle for real data. It stops short of an explicit 'use edgar_bundle when you need actual data' sentence, so not 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 it a read-only, idempotent, open-world operation, so the safety profile is covered; the description adds genuinely non-redundant behavior: paid ($0.02 USDC on Base via x402), live-fetched from data.sec.gov, wallet never custodied by the server, and the two-step challenge/retry handshake.

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 paid tag and the core resource description, then covers the payment flow in one compact sentence. Slightly redundant in restating the price and 'your own wallet pays' twice, but no sentence 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?

For a 4-param, 0-required tool with nested payment object and no output schema, the description discloses what is returned (concept value, period end, form, filed date), the data source, and the full payment handshake. Only the sibling/alternative routing is left implicit.

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 every field (cik, ticker, concepts, payment_header) is already documented in the schema, so the baseline is 3. The description echoes the payment_header mechanics but adds no syntax or format detail beyond the schema.

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

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

States a specific verb/resource combo: fetch key XBRL facts (Assets, Revenues, NetIncomeLoss, EPS) for a US-listed company by ticker or CIK, with the source (data.sec.gov). It is clearly distinct from filings/fulltext siblings, though it never names the paid-vs-preview sibling (edgar_company_facts_preview) that an agent would most need to disambiguate.

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

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

Gives an explicit operational workflow: call with no payment_header first to receive the x402 challenge, then re-call with the same business arguments plus the signed header. It does not, however, advise when to prefer this over the preview or the bundle/filings 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful context the annotations do not carry: it is free, requires no wallet or payment, and takes no arguments.

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 sentence, front-loaded with '[FREE]' and the preview intent. It is efficient, though 'No wallet, no payment' mildly restates the '[FREE]' / 'before paying' framing already established earlier.

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, but the description conveys that the return value is a representative sample of the paid tool's response. For a zero-argument, zero-cost preview that is sufficient; the only minor gap is not hinting at the fields the sample contains.

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 and the schema (empty object) already reflects that, so there is nothing to document. The description confirms 'no arguments needed', which matches the schema and removes any doubt about required input.

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 exact resource (SEC EDGAR XBRL company facts, via edgar_company_facts) and states precisely what this tool returns: a free sample response showing the shape. It clearly distinguishes itself from the paid sibling it previews.

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 a clear condition for use: run this before paying 0.02 USDC to inspect the response shape. It stops short of an explicit 'use edgar_company_facts when you need real data' sentence, but the alternative and its rationale are strongly 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?

Annotations cover read-only/idempotent/open-world, and the description adds substantial non-obvious behavior: a paid endpoint at a stated price, live fetch from data.sec.gov, the two-call x402 handshake, and the critical assurance that the calling agent's own wallet pays and the server never holds funds. That is exactly the kind of operational context annotations cannot express.

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 key facts (paid, resource, forms, output) but the price and payment mechanism are repeated three times across the bracket prefix and body, which costs space without adding 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 seven-parameter paid tool with a nested object and no output schema, the description covers return contents (URLs, timestamps), data source, and the full payment lifecycle. Only the routing versus sibling EDGAR tools is missing.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description restates the payment_header workflow but adds no syntax or precedence detail beyond it (e.g. that cik overrides ticker is in the schema, not here). Baseline 3 applies.

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

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

States a specific verb and resource (retrieve recent SEC filings) with scope: by ticker or CIK, enumerated form types (10-K, 10-Q, 8-K), plus what's returned (document URLs, acceptance timestamps). It does not explicitly distinguish itself from siblings like edgar_fulltext_search or edgar_company_facts, 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?

Gives clear procedural guidance for the payment flow ('call with no payment_header first'), but never says when to choose this tool over edgar_fulltext_search, edgar_company_facts, or edgar_bundle. Usage is implied by the resource description rather than contrasted with 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: it costs nothing, requires no wallet, no payment, and no arguments, which is exactly the behavior an agent needs before calling. It stops short of describing the response structure in detail.

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 sentence front-loaded with the [FREE] tag and the key constraints. Nothing is repeated or wasted; the cost, purpose, and auth requirements all appear immediately.

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

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

For a zero-parameter preview tool with full annotation coverage and no output schema, the description is nearly complete: it explains what is returned (a sample response), the cost (free), and the auth requirements (none). The only minor gap is that it does not describe the sample payload's fields, but a preview inherently defers that to the actual response.

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 are zero parameters and schema coverage is 100%, so the baseline is 4. The line 'no arguments needed' reinforces the empty schema rather than adding new semantics, which is appropriate for a no-arg tool.

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: it returns a sample response of the edgar_filings tool so the caller can see the output shape before paying. It names the sibling resource it is a preview of (edgar_filings / SEC EDGAR filings), letting an agent distinguish it from the paid sibling without opening the schema.

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

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

It gives a clear condition for use: run this to preview the shape before paying 0.02 USDC. The routing intent (free trial vs. the paid edgar_filings tool) is explicit, though it never states an explicit exclusion or contrast sentence naming the paid tool by name for the actual data.

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 (readOnly, idempotent, non-destructive, openWorld), yet the description goes further and discloses the cost ($0.02 USDC on Base), the x402 payment handshake, the free first call with no payment_header, and that the server never holds or spends a wallet. That is exactly the extra context annotations cannot express.

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 cost is front-loaded in a bracket tag and the routing rule comes before the payment mechanics. It is dense with no filler, though the closing payment sentences are slightly repetitive of both the schema and the opening tag.

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

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

For a paid read-only search with no output schema, the description supplies the complete picture an agent needs: what is searched, how to narrow it, when to prefer the sibling, and the full two-step payment procedure.

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%, including a fully spelled-out payment_header object, so the schema carries the parameter semantics. The description's payment-flow narrative (call with no header first, then resend with the signed header) largely restates what the schema already documents, so it adds little beyond 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?

States a specific verb+resource (searches the actual TEXT of SEC filings) plus scope (since 2001, any company, by phrase) and even names the upstream index it uses. It explicitly contrasts itself with sibling edgar_filings, so an agent can disambiguate without opening either 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?

Gives an explicit routing rule: use this when you don't know which company filed, use edgar_filings once you do. That is a clear when-to-use / when-to-use-something-else statement naming the concrete 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 cover read-only/idempotent/open-world safety, so the bar is lower, but the description adds genuinely non-structured context: this call is free, requires no wallet or payment, takes no arguments, and returns a representative sample rather than real query results. That cost/payment and static-sample behavior is not derivable from 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?

A single sentence front-loaded with the [FREE] tag and the tool's identity, then the reason and the friction-free terms. Every clause carries information and nothing is padded.

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

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

For a zero-arg preview with no output schema, the description tells the agent what comes back (a sample response showing the shape) and that no inputs or payment are needed. It does not describe the sample payload's contents, which is a minor gap given there is no output schema to fall back on.

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?

Zero parameters and 100% schema coverage, so the baseline is 4. The description reinforces this with 'no arguments needed,' aligning with the empty properties object and preventing an agent from inventing query inputs.

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: a sample response for edgar_fulltext_search (SEC EDGAR full-text search), so an agent understands it returns preview data rather than live search results. It differentiates itself from the paid sibling by the [FREE] marker and the 'before paying 0.02 USDC' framing. What full-text search actually does is only implied via the parenthetical, but the preview contract is unambiguous.

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

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

It gives a clear context for use: inspect the response shape before committing 0.02 USDC, and notes no wallet/payment/arguments are required. The implicit alternative (use edgar_fulltext_search once you're ready to pay) is not named explicitly, so it stops just 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?

Adds substantial context beyond the annotations: a paid x402 flow with an explicit price, the wallet-ownership model ('your own wallet pays, never this server's'), the DNS sourcing method (own resolver, protocol-level), the static self-maintained disposable list heuristic, and the concrete limitation of no SMTP/inbox verification.

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 key 'PAID + price' fact, which is good, but it is one dense paragraph that repeats the 0.006 USDC/Base price and the no-vendor/wallet assertions more than once, adding 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?

With no output schema, the description implies return content by listing the checks and 'flags', and it fully explains the payment prerequisite. It stops short of describing the actual response shape, which would help close the gap left by the missing output 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 both the email and payment_header parameters are fully documented in the schema. The description restates the two-step payment flow but adds no syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb+resource and enumerates exactly what is validated (syntax, MX/A-fallback deliverability, disposable/role/free-webmail flags, SPF/DMARC), plus explicitly what it does NOT do (no SMTP connection, no inbox confirmation). It also distinguishes itself from a sibling by noting 'same sourcing as 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?

Gives clear call flow ('Call with no payment_header first to receive the payment requirements') and clarifies the boundary that it never confirms a specific inbox. However, it never names the obvious free alternative email_validate_preview or states when to prefer one over the other.

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 readOnly, idempotent, openWorld, and non-destructive. The description adds that the call is free, requires no wallet/payment, and takes no arguments, which is useful cost and auth context 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 front-loaded and compact: one sentence plus a short follow-up. Every clause (free, sample, purpose, cost, no wallet/payment/args) 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 no-param preview tool with rich annotations and no output schema, the description fully explains cost and usage. The sample response itself will reveal the output shape, so nothing critical 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?

Zero parameters, so the baseline is 4. The description adds 'no arguments needed,' which aligns with the empty schema but is not strictly necessary.

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 this is a free sample response for email_validate, letting the agent see the output shape before paying. It names the sibling email_validate and distinguishes the preview from the paid tool, so an agent can tell them apart without opening either schema.

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

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

It clearly positions the tool as a pre-purchase preview ('so you can see the shape before paying 0.006 USDC') and notes that no arguments are needed. It implies email_validate should be used for real validation but does not explicitly state the exclusion.

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 (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: paid access at 0.004 USDC on Base via x402, a 30-minute cache, ECB provenance, and the explicit guarantee that unsupported currencies are listed rather than guessed. It also clarifies wallet ownership ('your own wallet pays, never this server's'), which no annotation conveys.

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 paid tag and the core capability, then layers provenance and the payment workflow efficiently. There is mild redundancy — '0.004 USDC on Base via x402' appears in both the tag and the body, and the payment re-call is repeated from the schema — but no sentence 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?

For a 4-parameter, no-output-schema tool with a nested payment object, the description covers provenance, cost, caching, limitations, and the two-step payment dance thoroughly. It could say more about the shape of the returned rates, but the listing/never-guessed hint partially covers response expectations.

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 base, date, quotes, and payment_header are already documented, and 3 is the appropriate baseline. The description reinforces the payment_header workflow but adds no syntax or format detail the schema lacks.

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 opening sentence names a concrete resource (foreign-exchange reference rates), its scope (any base, up to 40 quotes, latest or historical back to 1999), and its provenance (ECB euro reference rates via Frankfurter). It also flags what it is not — 'end-of-day reference rates, not tradeable quotes' — which cleanly separates it from trading-oriented siblings like token_price.

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

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

Gives explicit operational guidance: 'Call with no payment_header first to receive the payment requirements' and re-call with the signed payload plus the same business arguments. It stops short of naming the free fx_rates_preview sibling or stating when-not to use the paid path, so the alternative routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-structured context: it is free, requires no wallet and no payment, and returns a sample rather than live data. It does not specify what the sample contains, but for a zero-arg preview that is a minor omission.

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 sentence that front-loads the [FREE] marker and moves directly through what it returns, why it exists, and what it costs. 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 zero-argument preview tool with full annotation coverage and no output schema, the description supplies everything needed to call it correctly: cost model and the fact that it returns a sample shape. It could be slightly more complete by stating when to graduate to the paid fx_rates, but 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 tool takes no parameters, so the baseline is 4. The description reinforces this with 'no arguments needed,' which is consistent with the empty schema and adds no misleading parameter claims.

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 exact resource (FX Rates, ECB reference rates via Frankfurter) and states precisely what this variant returns: a sample response for the paid fx_rates tool. It is immediately distinguishable from the paid sibling fx_rates and from unrelated siblings like weather_preview by naming the underlying tool it previews.

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

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

It gives clear context for use ('so you can see the shape before paying 0.004 USDC') and names fx_rates as the paid counterpart, implying the switch condition. It stops short of an explicit 'call fx_rates when you need real data' exclusion, so it is clear but not fully prescriptive.

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 read-only/idempotent/ open-world annotations, the description discloses that results are cached 30 seconds across all callers, the exact cost (0.002 USDC via x402), and the critical trust boundary that 'your own wallet pays, never this server's.' These are precisely the behavioral facts annotations cannot carry.

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 [PAID] tag and price are front-loaded, and the sentences are information-dense with little padding. The payment/wallet point is stated twice ('paid via x402 by the calling agent's own wallet' and 'your own wallet pays, never this server's'), a minor redundancy in an otherwise tight description.

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 enumerating the returned values, the units (gwei), the chain scope, the caching behavior, and the full payment handshake. An agent has everything it needs to invoke this tool correctly on the first attempt.

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, but the description adds sequencing meaning the schema cannot: that payment_header should be omitted on the first call and supplied on the retry with the same business arguments. It also pins the chain to base mainnet, reinforcing the enum.

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

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

The description names a specific verb and resource ('Current Base gas market read live from Base's own public JSON-RPC') and enumerates the returned values (legacy gas price, EIP-1559 base fee, priority/max fee, transfer cost estimate), clearly distinguishing it from a hosted gas-oracle vendor. It does not explicitly differentiate itself from the sibling gas_price_preview, so it falls just 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 two-step x402 invocation pattern is spelled out concretely: 'Call with no payment_header first to receive the payment requirements' then call again with the signed header. It also scopes the tool to 'Base mainnet only (eip155:8453).' It offers no explicit comparison to the free gas_price_preview alternative, 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely useful context beyond them: no wallet, no payment, and no arguments required. The 'sample response' phrasing hints the data is illustrative rather than live, which is important behavioral context for a preview 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?

A single sentence that front-loads the '[FREE]' qualifier and the sample-response purpose, with no wasted clauses. The bracketed marketing tag is slightly noisy but costs little.

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 no-arg preview with no output schema, the description supplies the essentials: free, no auth, no payment, and that the response is a shape preview. It doesn't enumerate the fields in the sample, but that gap is minor at this complexity 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?

Zero-parameter tool, so the baseline is 4, and the description explicitly confirms 'no arguments needed', matching the empty schema and additionalProperties:false. Nothing further is required.

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: it returns a sample response for gas_price (Base gas price) so the shape can be inspected before paying. It clearly distinguishes itself from the paid gas_price sibling by naming the price gate (0.002 USDC), though it never says outright that it returns static/sample data rather than live values.

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 clear: call this before paying for the real gas_price to preview the response shape. The paid alternative (gas_price) is referenced implicitly via the price mention, but there is no explicit 'use gas_price when you need live data' routing sentence.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial behavior beyond them: a two-call x402 payment handshake, per-section parallelism with independent timeout guards, graceful degradation (a failing section returns status "unavailable" rather than failing the whole call), and per-section status/sources output. It also clarifies the server never holds a wallet, which is 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?

It is long but dense and front-loads the paid/pricing signal, then the section list, then failure behavior, then the payment handshake. Minor redundancy: the $0.05 price and "paid via x402" are stated three times, and the wallet-ownership point is repeated.

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 an 8-parameter composite tool with no output schema, the description covers the essentials: what runs and when, partial-failure semantics, the two-step payment protocol including the exact header shape to echo back, and cost. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents mutual exclusivity of name/ticker/lei/cik and the optionality of email/domain/wallet; baseline would be 3. The description adds routing semantics the schema cannot express — that any combination of identity/domain/wallet/email is allowed and that only sections backed by supplied arguments execute — which is genuine added value.

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 composite resource (a merged KYB report) and enumerates exactly which sub-reports it runs (company_lookup, sanctions_screen, domain_intel, wallet_profile, email_validate), each corresponding to a sibling tool. An agent can immediately distinguish this aggregator from the individual section tools without opening any schema.

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

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

It states the use case (compliance/onboarding) and the triggering condition clearly: supply at least one of name/ticker/lei/cik/domain/wallet/email, and only the implied sections run. It also frames the alternative economically (bought separately up to $0.064 vs flat $0.05), but never explicitly names a sibling like company_lookup or wallet_profile as the thing to use when you only need one section.

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 readOnly, idempotent, open-world, non-destructive. The description adds genuinely new behavioral facts: no wallet required, no payment charged, and no arguments needed. That payment/authentication context is exactly the kind of thing annotations do not carry.

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 front-loaded sentence with the [FREE] marker first and the value proposition up front. Slightly heavy nesting of parentheses (the pack's own title is inlined), 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?

For a zero-arg preview tool with no output schema, the description conveys the free/no-payment profile and names the categories the sample response covers, which is enough to call it correctly. It could say more about how the sample mirrors kyb_pack's real payload, but the essentials are 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 has zero parameters (100% coverage) and the description reinforces this with 'no arguments needed,' so the agent knows nothing must be supplied. Baseline for zero-param tools is 4; no additional parameter semantics are available to add.

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 this returns a sample response for kyb_pack so the caller can inspect the shape before paying, and enumerates the pack contents (identity, sanctions, domain, wallet, email). It is easy to distinguish from the paid kyb_pack sibling, though the resource description is largely restated from the parent tool's title rather than adding new precision.

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 a clear use context: call this to preview the shape before spending 0.05 USDC on kyb_pack. The alternative (the paid tool) is implied by the pricing reference. There is no explicit 'do not use for production data' exclusion, but the intent is 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 read-only, idempotent, non-destructive behavior. The description adds material context not in annotations: the operation is free and avoids paid routes, which matters on a paid API server. It does not detail auth or rate limits, but that is not critical for a read-only catalog.

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?

Single sentence, front-loaded with the [FREE] marker and core purpose. Every phrase contributes: catalog scope, included price/description metadata, and the no-paid-route constraint.

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

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

For a zero-parameter, read-only catalog endpoint with no output schema, the description supplies the catalog scope, included metadata, and free/no-paid-route behavior. Annotations cover safety traits, so no necessary context 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?

Zero-parameter schema with 100% description coverage; baseline is 4. No parameter meaning needs to be conveyed, and the description does not need to compensate for schema gaps.

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 ('Returns'), specific resource ('full tool catalog'), included metadata ('prices and descriptions'), and a clear differentiator ('without calling any paid route'). This cleanly separates it from paid endpoint siblings and preview variants.

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?

Signals when to use it via '[FREE]' and 'without calling any paid route', implying it is the discovery step before invoking paid routes. It does not explicitly name alternative discovery tools, but the routing condition 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 read-only/idempotent/open-world/non-destructive, yet the description adds substantial context beyond them: the paid x402 model and price, the fact that the first call returns a payment challenge for free, that the calling agent's own wallet pays and the server never holds one, and that it returns headlines/URLs/metadata only and never relays article body text.

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 price tag and core capability, and each sentence is largely functional. The payment mechanics are stated twice within the description ('Call with no payment_header first...' and '$0.009 USDC on Base, paid via x402...'), which is mild redundancy in an otherwise dense, well-ordered block.

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 an 11-parameter paid tool with a nested payment_header object and no output schema, the description covers the critical unknowns: the payment handshake, what the return contains, and the timeline-vs-articles behavior. An agent has everything needed to call 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%, so the baseline is 3. The description still adds meaning beyond the schema by explaining what mode:'timeline' actually returns (volume+avg-tone series) and by consolidating the timespan range, sort options, and max_records bounds, though most individual parameter meaning is already in the schema.

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

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

States a specific verb+resource ('Multi-language, multi-country news headline search plus an optional volume/tone timeline') and grounds it in a named data source (GDELT DOC 2.0). An agent can distinguish it from siblings like crypto_news or social_trends_pulse without opening the schema.

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

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

Gives clear usage context: pass mode:'timeline' for a per-period volume+tone series instead of an article list, and explains the required first-call-without-payment flow. It does not name a sibling alternative (e.g. news_search_preview, crypto_news) or state exclusions, so it stops short of the 5 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 cover readOnly, idempotent, openWorld, and non-destructive. The description adds genuinely useful non-schema context: it is free, requires no wallet/payment, and takes no arguments. It stops short of describing the sample payload itself, but the added cost/auth context is real value 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?

A single sentence that front-loads the [FREE] preview nature. It is somewhat cluttered by repeating the full tool title in nested parentheses, but there is no wasted exposition.

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

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

For a zero-argument preview stub with no output schema, the description says everything needed: what it returns (a sample response), why (see the shape), and the cost/auth model (free, no wallet). Nothing an agent needs in order to call it correctly is missing.

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

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

Zero parameters, so the schema carries no argument semantics to explain. Baseline is 4 per the rules; the description confirms 'no arguments needed', which matches the empty schema.

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

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

The description clearly states this returns a sample response for the paid news_search tool so the agent can preview the output shape. It explicitly names the sibling news_search and the free/paid distinction, but the phrasing is meta rather than a crisp 'returns X' statement, and it leans on the title for the actual subject matter (GDELT, multi-language, tone timeline).

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

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

It gives clear context: this is the free preview to inspect 'before paying 0.009 USDC', with 'No wallet, no payment, no arguments needed'. This tells the agent when to call it (before committing to the paid sibling) though it never explicitly instructs 'use this instead of news_search for testing'.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing hard limits (10 MiB, 40 pages/call), the SSRF-hardened fetch, and the critical failure mode that scanned/image-only PDFs return empty text with a warning rather than a fabricated OCR guess. The payment flow (server never holds a wallet, caller's wallet pays) is also spelled out, which annotations cannot 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?

Front-loaded with price and purpose, then capabilities, then constraints, then payment mechanics. Dense but nearly every clause carries information; the repeated '$0.04 USDC on Base' statement is the one mildly redundant element.

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 covers the return shape (per-page plain text + metadata), the degenerate case (empty text + warning for image-only PDFs), and the full payment lifecycle, so an agent has everything needed to call it correctly on the first attempt.

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 already 100%, so the baseline is 3; the description adds real value on top by restating the url/pdf_base64 mutual exclusivity, the 10 MiB decoded cap, and the semantics of the payment_header two-step handshake that the schema documents only partially.

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 ('PDF -> per-page plain text + metadata') plus the exact mechanism (pdfjs-dist) and explicit negations (no OCR, no tables, no vendor), which separates it from generic extraction tools and from the pdf_extract_preview sibling implied by the catalog.

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

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

Gives clear operational guidance: pass exactly one of `url` or `pdf_base64`, and make a first call with no payment_header to receive the x402 challenge before paying. It does not, however, explicitly name a sibling alternative (e.g. pdf_extract_preview) or state when a different tool would be preferable.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds that no wallet/payment is required and no arguments are taken, but it doesn't disclose whether the returned sample is fixed/canned data, how representative it is, or any rate limiting on preview calls.

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

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

A single sentence, front-loaded with the [FREE] tag and the key purpose. It is appropriately sized for a zero-argument preview tool, with only mild redundancy between the parenthetical title and the sentence body.

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

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

For a zero-arg, no-output-schema preview tool with full annotations, the description covers purpose, cost model, and input expectation adequately. The only minor gap is not clarifying that the returned sample is static and unrelated to any real document.

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?

Zero parameters with 100% schema coverage gives a baseline of 4. The description reinforces this by confirming 'no arguments needed', which matches the empty schema and prevents an agent from hunting for inputs.

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 resource and scope: it returns a free sample response for pdf_extract so the caller can inspect the response shape. It clearly distinguishes itself from the paid sibling pdf_extract by noting the free/no-payment nature, though the framing is closer to marketing copy than a crisp verb+resource statement.

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 usage condition well: use this to preview the response shape before paying 0.04 USDC for the real pdf_extract. It doesn't name pdf_extract as the explicit follow-up alternative in a 'use X instead' form, but the pricing reference makes the when-to-use case obvious.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial context beyond them: this is a paid x402 tool, the calling agent's own wallet pays, the server never holds a wallet or pays on its behalf, and the change data comes from OFAC's own feed rather than a self-diff of snapshots. That is exactly the kind of behavior an agent needs before invoking.

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

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

Front-loads price, then purpose, then the differentiation, then the payment mechanics, so the important routing signal comes first. Slightly redundant in stating the 0.008 USDC/Base price twice, but every sentence otherwise 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?

The payment mechanics, data provenance, and required parameters are covered thoroughly enough for a nested-object, 5-param tool. With no output schema, it does not describe the return shape (e.g., the list of publications and fields), which is the main remaining gap.

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 all five parameters (limit, since, crypto_only, entity_type, payment_header) are already documented in the schema. The description reinforces the crypto/change semantics and the payment_header flow but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb+resource: which OFAC SDN entries and crypto wallet addresses were added, removed, or modified since a date, sourced from OFAC's official change-tracking feed. It explicitly contrasts its scope with a point-in-time screening check, so an agent can distinguish it from sanctions_screen without opening the schema.

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

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

Gives clear usage context ('what changed since I last screened' vs 'is this on the list right now') and the payment invocation flow (call with no payment_header first, then re-call with the signed header and the SAME business args). It does not name the alternative sibling (sanctions_screen) directly, so routing is implied 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?

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds useful context beyond that: it is free, requires no wallet, no payment, and no arguments, which lowers uncertainty about invocation cost and side effects.

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 compact sentence with the free preview purpose and invocation constraints front-loaded. Every clause earns its place and there is no repetition 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 no-argument preview tool with no output schema, the description gives sufficient context: it is free, returns a sample shape, and requires no wallet or payment. It could add whether the sample is static, but the annotations already cover idempotence and safety.

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?

With zero parameters, the baseline is 4. The description reinforces this with 'no arguments needed,' which matches the empty schema and is helpful for an agent deciding whether to call it.

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

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

The description clearly states this is a free sample response for sanctions_delta, named as OFAC sanctions list change tracking. It distinguishes itself from the paid sibling by being a preview, but it does not state a specific operation verb (e.g., 'returns a sample payload') beyond 'sample response'.

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 to use this to see the shape before paying 0.008 USDC and notes no wallet or payment is required. The alternative (paid sanctions_delta) is named, though the description does not spell out conditions like when the paid version 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 cover safety (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar is lower, yet the description still adds useful behavior: live fetch rather than a stale snapshot, and an explicit custody statement that the server never holds a wallet or pays on the caller's behalf. This is material context beyond the structured hints.

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

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

The pricing is front-loaded, which is appropriate, but the same fact is repeated three times ('0.006 USDC on Base via x402', '$0.006 here vs its $0.01', '$0.006 USDC on Base, paid via x402'). The wallet-custody sentence is also echoed in the payment_header schema description, so the prose is longer than the payload warrants.

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 should ideally indicate what a screen returns (match/no-match, score, matched alias), but it never describes the response shape. The payment and screening mechanics are complete, yet an agent still cannot predict the result format before calling.

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 every parameter (name, type, lists, wallet, threshold, payment_header) is already documented in the schema, including the fuzzy-vs-exact match semantics and the notes that 'pep' is not screened. The description mostly restates the type/threshold/lists fields as compatibility knobs without adding new syntax, 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?

States a specific verb and resource: 'Screen a name and/or crypto wallet address against the U.S. Treasury OFAC SDN list'. It scopes what is matched (primary names, aliases, digital-currency addresses) and notes it comes live from the official export service. It does not distinguish itself by name from nearby siblings like sanctions_screen_preview, sanctions_delta, or bundle_sanctions_100, so differentiation relies on 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?

The payment flow is spelled out precisely: call with no payment_header first to get the challenge, then retry with the signed header using the same business arguments. However, there is no guidance on when to choose this tool over sanctions_screen_preview or sanctions_delta, so the sibling-selection question is left unanswered.

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 readOnly, idempotent, openWorld, and non-destructive. The description adds cost and auth context not in the structured fields: free, no wallet, no payment, no arguments. It does not describe the sample payload's contents, but the cost/auth disclosure is genuine added value.

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 sentence, front-loaded with the [FREE] marker. It is efficient, though the "(OFAC sanctions screen)" parenthetical partly duplicates the title and the phrase is slightly dense.

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 preview tool whose entire purpose is to reveal the response shape, there is no output schema and the description never says what the sample actually contains. It conveys the cost model but not the payload an agent would use to decide whether to call the paid 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?

Zero parameters, so the baseline applies. The schema covers the (empty) parameter set fully and the description correctly notes 'no arguments needed', leaving nothing ambiguous.

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 exactly what it is: a free sample response for sanctions_screen (OFAC sanctions screen), explicitly framed as a preview before paying. This cleanly distinguishes it from the paid sibling sanctions_screen and the other *_preview 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?

"See the shape before paying 0.006 USDC" gives clear context for when to reach for this tool versus the paid sanctions_screen. It stops short of explicit when-not guidance (e.g., that it returns sample data unsuitable for real screening), so it is clear but not fully routed.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes further by disclosing the paid x402 flow: cost ($0.07 USDC on Base), that the calling agent's own wallet pays and the server never does, and the first-call-without-payment_header challenge pattern. This is material behavioral context an agent cannot get from 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?

Front-loaded with the paid notice and when-to-use, but the prose is repetitive: the $0.07 cost, 'buy signal_history for that', and 'stored editions, not calendar days' each appear roughly twice, and the wallet-payment point is restated. Tighter editing would preserve all value in less space.

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

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

For a paid, no-output-schema tool this is comprehensive: it explains cost, payment mechanics, the challenge-first call pattern, and what the returned analysis represents (continuity states across N editions). Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema description coverage is 100%, so both parameters are already fully documented, including the 'stored editions, not calendar days' nuance and the payment_header signing workflow. The description reinforces these but adds essentially no meaning beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource — surfacing which signal ids/topics are stable, rising, new, or fading across stored editions — and names exactly which siblings it is not (signal_history, signal_topic_trace). An agent can distinguish it from siblings 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?

Explicit when-to-use ('when you want to see which threads persist, rise, appear or fade across days, without paying for the full briefs') plus explicit when-not with named alternatives for both cases (signal_history for full text, signal_topic_trace for one thread's path). Nothing 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, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful preview-specific context: it is free, requires no wallet or payment, takes no arguments, and exists to show response shape before purchase. It does not state sample limitations or freshness, so it falls 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?

The description is front-loaded with [FREE] and the core purpose, then immediately covers buy/skip conditions and alternatives. Every sentence earns its place, and there is 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 zero-argument preview tool with rich annotations and no output schema, the description provides everything an agent needs: what it is, when to use it, when to avoid it, alternatives, cost, and argument expectations. No material gap remains.

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?

With zero parameters, the baseline is 4. The description reinforces that no arguments are needed, which matches the empty schema and removes ambiguity for an agent considering the call.

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 returns: a free sample response for signal_continuity, a cross-day continuity map. It distinguishes the preview from the paid sibling and from other signal tools, so an agent can tell what it is without opening the schema.

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

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

It gives explicit when-to-buy guidance for the full tool versus when to skip the preview, and names concrete alternatives (signal_history, signal_topic_trace). This is unusually strong routing for a preview endpoint.

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 readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: paid x402 flow, first call without payment_header returns the challenge free, wallet model ('your own wallet pays, never this server's'), free 404 with payment_taken false for unstored dates, and the mutable-revision caveat that it is not an as-of backtesting snapshot. This is exactly the behavioral disclosure a paid, side-effecting-network tool needs.

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 paid price and the core scope distinction, and every paragraph carries decision-relevant content. It is dense and slightly repetitive on pricing ('[PAID — 0.04 USDC...]' plus a second full price sentence plus 'cheaper than buying full history'), which costs a point.

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

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

No output schema exists, so the description carries the return contract and does: what the body looks like ({ date }), what comes back (the date's stored revision), and how to identify it (brief.generated_at, brief_sha256, sha256 previewed free). Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and both parameters are already well documented, so the baseline is 3; the description adds real meaning by pointing to /health archive_dates and the free editions.json for choosing a valid date, and by clarifying payment_header round-tripping. It stops short of explaining the date format itself, which the schema covers.

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 ('ONE stored date's full Signal brief') and explicitly distinguishes itself from signal_latest and signal_history by the scope each covers. An agent can pick between the three 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?

Explicit when-to-use ('full brief currently stored for one date, e.g. to review judgments and sources') and when-not ('not the most recent edition → signal_latest; not several consecutive days → signal_history'). Alternatives are named with their trade-off (flat price).

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered structurally. The description adds genuinely new context: it is free, requires no wallet or payment, takes no arguments, and returns a sample shape rather than the full brief. Only minor gap is not stating how the sample differs in size/coverage from the paid response.

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 [FREE] marker, then purpose, then buy/skip routing in three compact sentences. No filler and no repetition of the title or schema.

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

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

For a zero-param preview with no output schema, the description covers what it returns (a sample shape), what it costs (nothing), and how it relates to the paid sibling. Slightly short of complete because it doesn't say how representative or truncated the sample is.

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?

Zero-parameter tool, which sets a baseline of 4, and the description confirms it explicitly with "no arguments needed" and "no wallet, no payment" — aligning with the empty schema rather than contradicting it.

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

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

States specifically that this is a free sample response for signal_day, letting the agent see the response shape before paying. It distinguishes itself from signal_day (paid, full brief), signal_latest (most recent edition), and signal_history (multi-day) by name.

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

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

Gives an explicit when-to-use ("Buy signal_day when you want the full brief stored for one date") and when-to-skip with named alternatives for both the recency case (signal_latest) and the multi-day case (signal_history). Nothing 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 readOnly/idempotent/non-destructive/openWorld, but the description adds the traits they cannot express: it is a paid call (0.05 USDC via x402), the caller's own wallet pays, there is a free availability pre-check (GET /v1/signal_delta/availability?since_date=...), and the two-step payment flow (first call without payment_header to receive the challenge, then re-call with the signed header). This is exactly the kind of auth/cost context annotations don't cover.

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 cost and the routing condition, and almost every sentence carries information. However, the 'cheap repeat check' idea is restated three times ('the cheap repeat check', 'a cheap stay-current check', 'the intended repeat purchase'), which adds mild redundancy.

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

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

For a paid, two-step tool with no output schema, the description covers the return contents, the free availability endpoint, the payment handshake, and cost. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so since_date and the payment_header flow are already documented in the schema and the description only reiterates them. It adds no syntax or format detail beyond the schema, so the 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?

States a specific outcome — the change list (new, changed, removed Signal headlines) since a baseline date — and explicitly distinguishes itself from signal_latest and signal_history in the same sentence. An agent can route correctly without opening any sibling 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?

Gives explicit when-to-use ('when you already hold an earlier dated brief and only want what changed since that date') and explicit when-not ('Not when you hold no brief yet (use signal_latest) or want the full briefs (signal_history)'), naming the alternatives and the condition that selects each.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuinely useful non-annotation facts: it is free, requires no wallet and no payment, and takes no arguments — critical context in a pay-per-call family where cost is the main decision factor.

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 [FREE] marker and the core purpose, then layers routing guidance. It is a single dense paragraph with some parenthetical nesting, but every clause carries routing or cost information rather than 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?

No output schema exists, but the description explains that the tool returns a sample of signal_delta's response so the shape is visible before purchase, which is the essential expectation to set. Nothing needed to invoke a zero-argument preview 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?

Zero parameters, so the baseline is 4. The description reinforces this with 'no arguments needed,' which prevents an agent from hunting for a required date parameter that does not exist.

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

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

States a specific verb and resource — a free sample response of signal_delta's 'change list' output — and immediately names the siblings it differs from (signal_delta, signal_latest, signal_history). An agent can distinguish this preview from the other signal_* tools 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?

Gives explicit routing: use signal_delta when you already hold a dated brief, use signal_latest when you hold none, use signal_history for full briefs. The when-not conditions describe the paid family rather than the preview itself, but the implied trigger for this tool (see the shape before paying) 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 readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: the x402 payment flow (call once with no payment_header to get the challenge, then pay from the caller's own wallet), the flat $0.10 USDC pricing, the no-wallet custody model, and the crucial semantic that N counts stored editions, not calendar days. This is rich context an agent genuinely needs.

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 paid marker and the core situation, and every claim is substantive. Slightly repetitive, though: flat pricing is stated three times ('one flat price', 'flat-priced regardless of count', '$0.10 USDC on Base') and the no-wallet clause appears in both description and schema.

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

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

No output schema exists, yet the description tells the agent the return shape (one full brief per date, oldest first) and fully documents the payment handshake. For a paid, 2-parameter archive tool, an agent has everything needed to call it correctly on the first and second attempt.

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, but the description adds real meaning beyond the schema: it clarifies that 'days' counts stored editions rather than calendar days and that returned dates can therefore span more than N days, plus points to /health archive_dates for the available dates. That is value the schema's own wording does not fully deliver.

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: retrieving the last N stored Daily Agent Signal editions (1-30), oldest first, one full brief per date. It explicitly differentiates itself from sibling tools signal_latest, signal_day, and signal_continuity, so an agent can route without opening another 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?

Explicitly names when to use it ('several recent days at one flat price') and when not to, with the exact alternative for each rejected case (signal_latest for the most recent edition, signal_day for one past date, signal_continuity for thread persistence without full text). Nothing 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 cover safety and idempotency (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds key context the annotations cannot: the response is a sample/fixture rather than real briefs, it costs nothing, and it requires no wallet. It stops short of describing sample completeness or how the preview differs in coverage from the paid payload.

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 sentences, front-loaded with the [FREE] tag and the sample-response framing before routing advice. Every sentence carries distinct information (cost, when to buy, when to skip with alternatives, invocation cost), with no padding.

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 parameters and no output schema, the description's only obligations are to explain what the preview returns, that it is free, and how it relates to the paid tool and siblings — all covered. Minor gap: it does not indicate whether the preview data is representative in breadth (how many days) or whether paid output has a different format.

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?

Zero parameters, so the baseline is 4. The description reinforces this with 'no arguments needed', which matches the empty schema and prevents an agent from trying to invent a date range or day count.

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 artifact (a free sample response for signal_history) and the resource it previews (multi-day archive of Daily Agent Signal). It explicitly names the sibling it is NOT (signal_history) and the preview relationship, so an agent can distinguish it from the paid tool and from the other signal_* variants.

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

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

Gives explicit when-to-use for the paid sibling ('Buy signal_history when you want the full briefs for several recent days') and when to skip it, with three named alternatives for the closest edge cases (signal_latest for most recent, signal_day for one date, signal_continuity for thread persistence). Nothing 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 declare readOnly/idempotent/non-destructive/openWorld, but the description adds substantial behavior beyond them: it is a paid x402 endpoint ($0.03 USDC on Base), editions are not published daily so the date must be checked in /health, and the two-step payment handshake (call with no payment_header first to get the challenge, then resubmit with the signed header). It also clarifies the calling agent's own wallet pays, never the server.

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 [PAID] tag and usage routing, and every sentence carries information. It is dense with parentheticals and repeats the payment mechanics across the body and the closing sentences, so it is slightly longer than strictly needed.

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

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

No output schema, but the description enumerates the returned fields (curator judgment, buyer_value, action_hint, sources, multi-day continuity). For a paid, single-optional-param read tool, the payment flow, freshness caveat, and return content are all covered, leaving nothing an agent needs missing.

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

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

Schema coverage is 100% and the nested payment_header field is already fully documented in the schema, so baseline would be 3. The description adds marginal workflow meaning by restating the free first call and the requirement to resend the SAME business arguments with the signed header, reinforcing the parameter's intended use.

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 resource (the most recent stored Daily Agent Signal edition) and its content scope (curator judgment, buyer_value, action_hint, sources), and explicitly names the siblings it is not (signal_delta, signal_day, signal_history). An agent can distinguish it from all four signal_* siblings 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?

Gives explicit when-to-use (start here if you hold no brief yet; want the most recent stored edition) and when-not (already hold an earlier brief and want only changes → signal_delta; one past date → signal_day; several full days → signal_history). The alternative routing is fully specified with 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 declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds context the annotations cannot: it is free, needs no wallet or payment, takes no arguments, and that editions are not published daily (check /health for the date). That is meaningful additional behavioral context.

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

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

The '[FREE]' tag and the sample-response purpose are front-loaded, and each clause routes the agent somewhere useful. It is somewhat long and devotes most of its text to when to buy the paid sibling rather than the preview itself, but no sentence 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?

With no output schema and zero parameters, the description carries the burden of orienting the agent. It describes the artifact ('the ranked judgment on agent-economy demand') and the payment/routing context well, though it does not describe the preview's actual return shape or size, which would fully close the loop for a preview 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 tool takes zero parameters, which is the baseline-4 case. The description reinforces this ('No wallet, no payment, no arguments needed'), so nothing is missing and nothing needs compensating.

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 ('A sample response for signal_latest ... see the shape before paying 0.03 USDC') and immediately frames its identity as the free preview variant, distinguishing it from the paid sibling and the other signal_* tools. An agent can tell what this returns without opening the schema.

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

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

It gives explicit when-to-use ('Buy signal_latest when you want the most recent stored edition'), when-to-skip ('Skip it when you already hold an earlier brief'), and names the correct alternatives for each case (signal_delta, signal_day, signal_history). Nothing 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?

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the x402 payment protocol: a free first call with no payment_header to receive the challenge, then a re-call with the signed header paying 0.06 USDC from the caller's own wallet. This two-step payment flow is critical, non-obvious behavior not captured by any structured field.

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

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

Front-loads the cost and the usage decision, and every sentence is functional. Slight redundancy in restating the 0.06 USDC / x402 / self-pay detail twice (bracketed tag and closing sentences) costs it a point.

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

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

No output schema exists, yet the description enumerates the returned fields (dates, headlines, judgments, vs_prior, ranks) and fully explains the payment handshake. An agent has everything needed to call correctly, including the pay flow and return shape.

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, topic, days, and payment_header. The description reinforces the 'provide exactly one of topic or id' constraint but adds no syntax or format meaning 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?

States a specific verb (trace) and resource (ONE topic or ONE signal id across every dated edition/brief), and explicitly contrasts itself with signal_continuity and signal_day. An agent can identify the tool without opening the schema.

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

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

Names both when to use (following one thread's path through every edition) and when not to, routing to specific siblings (signal_continuity for all-thread status, signal_day for a day's brief). Also adds a cost-based selection cue: cheaper than full history when you care about one thread.

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 (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description adds behavior those annotations cannot express — that it is free, needs no wallet/payment, takes no arguments, and returns a sample shape rather than the real trace. It does not detail the sample payload, but that is minor for a preview.

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 [FREE] tag and purpose in the first clause, then the buy/skip routing in two following sentences. Every sentence carries distinct information; nothing is repeated from the name or title.

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 no-argument, no-output-schema preview tool, the description covers what it returns (a sample response shape), its pricing model, its scope, and the alternatives. Nothing an agent needs to call it correctly is missing.

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

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

Zero parameters, so the schema carries nothing to clarify and the baseline is 4. The description correctly reinforces this by stating 'no arguments needed,' which is the only parameter-relevant fact for a no-arg tool.

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 the exact operation (sample response for signal_topic_trace) and its scope (single signal id trace across every dated edition), and explicitly distinguishes itself from the signal_continuity and signal_day siblings. An agent can identify this as the free preview variant 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?

Gives explicit when-to-use ('Buy signal_topic_trace when you follow one thread') and when-not ('Skip it when you want every thread's status at once (use signal_continuity) or a whole day's brief (signal_day)'). Both alternatives are named with the condition that selects them.

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

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

The description goes well beyond the annotations (which only cover read-only, open-world, idempotent, non-destructive). It discloses the payment model (0.015 USDC on Base via x402), that the calling agent's own wallet pays and the server never holds a wallet, that each source is independently optional so a failing upstream degrades gracefully, and the dedup/ranking behavior (cross_source flag, rank-based combined_score). This is rich operational context an agent needs to invoke it correctly.

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 key facts: paid cost, merged feed, and source list come first. It is somewhat dense and repeats the payment amount twice ('0.015 USDC on Base' and '$0.015 USDC on Base'), which is minor redundancy, but every sentence otherwise 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?

Given a 3-parameter tool with no output schema and annotations that only cover safety, the description supplies the missing context: payment flow, degradation behavior, dedup semantics, and the trade-off vs. wiki_trends_pulse. Nothing an agent needs to call it correctly appears to be missing.

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

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

Schema description coverage is 100%, so the schema already documents limit, sources, and payment_header in detail. The description adds only marginal parameter meaning beyond the schema (e.g., reiterating that payment_header is omitted on the first call), so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('merged trending-topics feed') and enumerates the exact four sources (Hacker News, Lobsters, Mastodon, Wikipedia). It also explicitly differentiates from the sibling wiki_trends_pulse, noting it is 'cheaper and broader.' An agent can distinguish this from wiki_trends_pulse and social_trends_pulse_preview without opening the schema.

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

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

Provides a specific call pattern: 'Call with no payment_header first to receive the payment requirements,' then call again with the same business arguments plus the signed header. It also names wiki_trends_pulse as the narrower alternative. It lacks explicit when-not-to-use guidance (e.g., when to prefer a paid, non-preview tool vs. the preview sibling).

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, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond those: the response is a sample, no wallet or payment is required, and the paid tool costs 0.015 USDC. It does not mention rate limits or whether returned data is live versus illustrative.

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 front-loaded sentence with the [FREE] tag first, then purpose, then payment/argument constraints. Every clause adds information and there is 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 zero-argument preview with rich annotations, the description states what it is, that it is free, and that no input is needed. It could briefly describe the sample content (multi-source social/trending topics) beyond the parenthetical, but it is adequate 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?

Zero parameters with 100% schema coverage, so the baseline is 4. The description confirms 'no arguments needed', which aligns with the empty input schema and avoids any confusion for the agent.

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 it is a sample response for social_trends_pulse and names the paid sibling immediately, with [FREE] front-loaded. An agent can distinguish it from the paid tool, though it doesn't differentiate itself from the many other *_preview 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?

Explicitly frames the use case: 'see the shape before paying 0.015 USDC' and notes no wallet, payment, or arguments are needed. It implies the paid social_trends_pulse as the alternative but doesn't state when to switch to it, keeping this 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 cover readOnly/idempotent/openWorld/non-destructive, but the description adds substantial context beyond them: 5-minute caching, a low-liquidity flag, a defined 'unsupported-token error — never a fabricated price' behavior, and the full x402 payment flow where the caller's wallet pays and the server never does. This is exactly the behavioral disclosure the annotations do not carry.

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 key facts are front-loaded ([PAID] tag, price source) and most sentences are load-bearing. There is mild redundancy — the '$0.003 USDC on Base via x402' cost and the 'your own wallet pays, never this server's' rule appear more than once — which costs it a point.

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 describing the return shape (leader-compatible prices[]/asOf/count/unresolved). It also covers caching, error behavior, and the payment handshake, so nothing an agent needs to invoke this 5-param, nested-object tool correctly is missing.

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

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

Schema coverage is 100%, so the schema documents every parameter including the payment_header nested shape. The description reinforces the batch nature of `coins` and its leader-compatible semantics, but adds little syntax or format detail beyond what the schema already states — the baseline 3 for full schema coverage.

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

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

The description states a specific verb and resource ('Base token price read live from on-chain state') and names the exact pricing sources (Chainlink Data Feed aggregators on Base, deepest Uniswap V3 USDC pool). An agent can tell this apart from gas_price, crypto_news, and the other siblings without opening the schema.

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

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

It gives a clear calling workflow ('call with no payment_header first to receive the payment requirements' then retry with the signed header) and states the pricing path selected per input type. It does not explicitly name the free sibling token_price_preview as the alternative for no-payment use, which keeps this from 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 readOnly, openWorld, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: no wallet, no payment, no arguments, and a sample response rather than real-time data. It stops short of saying whether the sample is static or how it is produced, but this is a useful addition.

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, front-loaded sentence that leads with [FREE] and then explains the preview purpose and its zero-argument, no-payment nature. 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?

For a no-parameter, no-output-schema preview tool, the description covers the essential agent needs: it is free, safe, requires no inputs, and exists to show the response shape. It could say more about what fields the sample contains, but calling it inherently reveals that shape.

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?

With zero parameters, the baseline is 4 per the rubric. The description reinforces this by explicitly stating 'no arguments needed,' which aligns with the empty input 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 and resource: it returns a free sample response for token_price (Base token price via Chainlink/Uniswap), letting the caller preview the shape. It clearly distinguishes itself from its paid sibling token_price by labeling itself [FREE] and mentioning the 0.003 USDC cost of the real 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 gives a clear usage context — use this to see the response shape before paying for token_price — and names the paid alternative it precedes. It does not explicitly state 'use token_price for live data,' but the preview-before-payment framing makes the routing 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?

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), the description discloses the cost (0.005 USDC on Base), the payment protocol (x402), and crucially that the calling agent's own wallet pays and the server never holds a wallet or pays on its behalf. Payment-quoting behavior is fully surfaced, which is exactly the extra context annotations cannot carry.

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 paid marker and the data payload, then the payment mechanics. Efficient overall, but the 0.005 USDC cost and 'x402/paid via' framing are repeated across sentences, which is minor redundancy in an otherwise tight description.

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 return-value explanation and does so by enumerating the three bundled datasets. Combined with annotations covering the safety profile and the description covering the payment flow, an agent has enough to invoke it correctly. Return format particulars (fields, units, cadence) are not detailed, which keeps it just short of fully 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 single payment_header parameter already has 100% schema description coverage, and the description reinforces its two-phase role (omit first to get the challenge, include the signed payload second). It adds the payment-flow meaning on top of the schema rather than repeating it, though it adds little on the header's internal name/value structure.

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 resource and scope: U.S. public debt outstanding, Treasury operating cash balance, and current-quarter exchange rates, bundled from api.fiscaldata.treasury.gov in one call. An agent knows exactly what data it returns. It does not, however, explicitly name or differentiate itself from the sibling treasury_fiscal_snapshot_preview, which is the natural alternative.

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

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

Gives clear operational guidance: call once with no payment_header to receive the x402 challenge, then call again with the SAME business arguments plus the signed header. This is explicit and actionable. It misses only the when-to-use-vs-preview routing that would fully separate it from the free sibling tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world. The description adds genuinely useful context beyond them: the response is a canned sample, it is free, and no wallet or payment is involved — important to prevent an agent from mistaking sample data for live data.

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 sentence with the key qualifier '[FREE]' and the purpose front-loaded. Every clause earns its place; 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 zero-argument preview with a complete schema and no output schema, the description covers the essentials: what it returns (a sample shape), that it is free, and that no args are required. It stops short of describing what fields the snapshot contains, but for a preview tool this is acceptable.

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 the baseline is 4. The description explicitly confirms 'no arguments needed', which aligns with the empty schema rather than contradicting it.

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

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

The description states a specific resource (a sample response for treasury_fiscal_snapshot) and its purpose (see the response shape before paying). It clearly distinguishes itself from the paid sibling treasury_fiscal_snapshot by naming it directly.

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 when to use it — before paying 0.005 USDC, to inspect the shape — and notes no wallet/payment/arguments are required. It does not explicitly say to switch to the paid tool for real data, but that is strongly implied by 'before paying'.

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 safety (readOnly, idempotent, openWorld, non-destructive), but the description goes far beyond: it discloses the 0.03 USDC payment requirement, the x402 two-step challenge/sign flow, the 10-minute cache, the live data sources (Base RPC + Blockscout + OFAC index), and that the server never holds a wallet. These are exactly the traits an agent needs and none are duplicated from structured fields.

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

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

Front-loaded with purpose, then capabilities, then payment mechanics — logically ordered. It loses a point for repetition: pricing ('$0.03 USDC on Base') and the x402/self-pay point appear two to three times, which is redundant even if partly clarifying.

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 return-value burden and does so fully by enumerating the returned fields plus the additive alias names. Combined with the payment flow and caching details, an agent has everything needed to call and interpret 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%, so both address and payment_header are already documented in the schema, including the nested {name, value} shape. The description reinforces the payment_header pattern but adds little syntax or format detail beyond what the schema provides; a 3 baseline 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?

States a specific verb ('Profiles') and resource ('Base wallet/contract address') and enumerates exactly what is returned: is-contract, activity timestamps, tx counts, balances, counterparties, label hits, OFAC check, risk summary. An agent can distinguish it from wallet_profile_preview and the many signal_/bundle_ siblings 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?

Clearly explains the invocation pattern: 'Call with no payment_header first to receive the payment requirements; your own wallet pays, never this server's.' This is strong operational context. It stops short of explicitly contrasting with the free wallet_profile_preview sibling or stating when the paid version is warranted over it, so not 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 cover safety (readOnlyHint, idempotentHint, non-destructive), so credit goes to the added commercial behavior: it is free, requires no payment and no wallet. That cost/argument-free trait is genuinely useful context beyond the structured fields, though response content behavior is not detailed.

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 front-loaded sentence that leads with '[FREE]' and the fact it is a sample, then closes with the cost context. Slightly redundant in restating the parenthetical title inside the description, but otherwise 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?

With no output schema, the description appropriately states this returns a sample response showing the shape of wallet_profile, which is exactly what an agent needs to know for a preview endpoint. Nothing essential for calling a zero-argument preview 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 tool takes zero parameters, so the schema-coverage baseline is 4. The description confirms 'no arguments needed', which is consistent with the empty input schema and adds clarifying value.

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 resource (a sample response for wallet_profile) and its scope (activity, balances, OFAC check, risk summary), and its name/description make clear it is the free preview variant. An agent can distinguish it from the paid wallet_profile sibling without opening either 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?

Explicitly frames when to use it: 'so you can see the shape before paying 0.03 USDC', which routes the agent to this preview ahead of the paid call. It does not explicitly say 'use wallet_profile (with a wallet argument) when you need real data', so the alternative half of the decision 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?

Annotations are present (readOnly, openWorld, idempotent, non-destructive), but the description adds substantial context beyond them: cost, the x402 paywall handshake, 10-minute caching per query, required attribution string, licensing, and which provider returns alerts. This is exactly the extra behavioral detail the annotations cannot express, and nothing contradicts 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?

Front-loaded with the one-line purpose before elaborating on sources and payment. It is dense but nearly every clause carries information; the main redundancy is the price/payment restated at both start and end, which slightly pads an otherwise information-rich paragraph.

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

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

For a paid, multi-source tool with no output schema, the description covers what an agent needs: the payment flow, geographic routing logic, return fields (provider, attribution), caching, and provider-specific limitations. Nothing material for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including aliases, ranges, and the U.S.-only caveat. The description restates much of this (lat/lon vs location, forecast_days, alerts U.S./NWS-only) rather than adding syntax or format detail. Baseline 3 is appropriate since the structured schema does 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?

States a specific verb+resource and scope: "Current conditions + short forecast, worldwide." It is immediately distinguishable from weather_preview via the explicit paid marker ("[PAID — 0.004 USDC on Base via x402]") and names its data sources (NWS + MET Norway). An agent can tell what it does and that it differs from the free preview sibling without opening the schema.

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

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

Provides strong routing guidance: U.S. coordinates go to NWS with alerts, everything else to MET Norway without alerts, and it explains that address resolution is U.S.-only ("non-U.S. place names are never resolved this way"). It also explains the unpaid-first workflow. It stops short of explicitly naming weather_preview as the free alternative, so it lacks a true when-not clause.

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, idempotent, open-world behavior, but the description adds valuable context the schema cannot: it is free, needs no wallet/payment, and takes no arguments. The only gap is not clarifying that the returned payload is a static sample rather than live observations.

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 front-loaded sentence leads with '[FREE]' and the essential routing information. It is slightly inflated by the nested parenthetical re-stating the full title, which adds length without 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 no output schema, the description should ideally say something concrete about the returned weather shape it exists to preview, but it only asserts a sample exists. An agent knows how to call it (no args) but not what it will receive.

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

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

The tool takes zero parameters and the schema coverage is 100%, so there is nothing for the description to disambiguate. The line 'no arguments needed' correctly sets the zero-argument expectation, meeting the baseline for a no-param tool.

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 it returns a sample weather response so an agent can inspect the shape before paying, which is a specific action and distinguishes it from the paid sibling `weather`. What the sample actually contains (a fixed exemplar vs live data) is left ambiguous, but the preview nature is clear.

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

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

It gives clear context: use this to see the response shape before spending 0.004 USDC on the real tool. The implied alternative (`weather`) is referenced via the payment comparison, though it is never named explicitly, so there is no hard exclusion 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds substantial behavior the schema cannot express: it is a paid call ($0.025 USDC on Base via x402), the first call must omit payment_header to receive the challenge, the calling agent's own wallet pays, and the server never holds a wallet. That is exactly the kind of auth/payment flow context this dimension rewards.

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 paid/usage essentials and keeps the mode description tight, but the payment facts ('$0.025 USDC on Base', 'paid via x402') are restated, adding mild redundancy across an otherwise dense, purposeful block.

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 return-value burden and does so reasonably: it names the trending + breakout list, the daily series and trend stats, and the alias fields. A brief note on output shape/ordering would fully close the gap for this fairly complex, 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 coverage is 100%, so the baseline is 3, but the description adds real semantic value: it explains that keyword is an alias of article (provide one or the other), that article vs no-article selects the mode, and that the response carries Google-Trends-style alias fields (keyword/queried_at/series[].value). This goes beyond restating 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 resource (Wikipedia trending topics / topic-attention data) and its source (Wikimedia Pageviews REST API), and explicitly frames itself against the 'incumbent' Google Trends. The two operating modes (trending list vs article series) are spelled out, so an agent can distinguish it from siblings like social_trends_pulse without opening the schema.

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

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

Gives clear mode-selection guidance ('Omit article/keyword for today's most-viewed...; give article for that topic's daily pageview series') and context on when this is the right substitute for an unavailable alternative. It does not explicitly name a sibling tool (e.g. social_trends_pulse) as the alternative, which keeps it just below 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 cover read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: it is free, requires no wallet or payment, and discloses the 0.025 USDC price of the paid counterpart. It does not explain the returned payload beyond 'sample response'.

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 front-loaded sentence with the '[FREE]' tag first, then the tool identity, then the purpose. Every clause earns its place and there is no padding.

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

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

No output schema exists, so the description should at least sketch what the sample contains; it only says 'sample response' and never describes the trending-topic or attention-series fields. For a zero-param preview whose whole value is showing response shape, that is a real gap, though the routing/billing context is 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?

With zero parameters, the baseline is 4, and the description reinforces this by stating 'no arguments needed', which matches the empty schema with additionalProperties false. Nothing more is required.

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 specific parent tool it previews (wiki_trends_pulse), states its nature (a sample response), and explicitly distinguishes itself from the paid sibling by being free and requiring no wallet. An agent can tell immediately this is the zero-cost preview variant rather than the real data 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?

It gives a clear reason to call it — 'so you can see the shape before paying 0.025 USDC' — and confirms no arguments are needed. It stops short of explicitly naming wiki_trends_pulse as the follow-up call, but the intent and trigger condition are unambiguous.

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