Agent Data Tools

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the return-field exclusions, a three-second post-completion latency, a $0.01 USDC per-successful-call price on Base, and the x402-capable wallet prerequisite. These are exactly the operational facts an agent needs before invoking a paid, rate-shaped tool.

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

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

Four short sentences, front-loaded with what the tool does and what it returns, then constraints, latency, price and prerequisite. No filler, and each sentence carries distinct 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 fully compensates by enumerating returned fields, listing exclusions, and covering payment, latency and client requirements. An agent has everything needed to decide and invoke 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 are already documented; the description only reinforces the literal-phrase and 20-item caps. Baseline 3 applies since 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 (search arXiv) and enumerates exactly what is returned (IDs, titles, categories, dates, source links) and what is not (authors, abstracts, PDFs). The only gap is that it never distinguishes itself from the sibling openalex-papers, which serves a similar literature-search need.

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 in-tool constraints (one literal phrase, advanced syntax escaped, cap of 20) that imply how to call it, but offers no explicit when-to-use guidance and never mentions openalex-papers as an alternative for author/abstract coverage.

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 only readOnly/openWorld, so the description carries real added weight: it discloses that raw support statements, arrays, false/null and unresolved mirrors are preserved verbatim and that versions must never be inferred. It also reveals two costly operational facts an agent must know before calling — a $0.01 USDC per-successful-call charge on Base and the requirement for an x402-capable wallet client.

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 the core action and scope, followed by behavioral constraints and then the critical payment/auth requirements. It is dense but every clause earns its place; slightly more packing than ideal, but 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?

With no output schema, the description steps in to describe return semantics (preserved support statements, arrays, false/null, unresolved mirrors), and it discloses the payment and wallet prerequisites. For a 2-parameter read tool with payment gating, 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 description coverage is 100%, so both parameters (the enum-constrained browser and the exact BCD feature path) are already fully documented in the schema. The description only reinforces exactness ('one exact ... feature and browser') without adding format or syntax detail beyond the schema, 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 ('look up') and resource ('one exact MDN BCD feature and browser'), with the important scope constraint that it is a single exact lookup against the actor pinned release and verified Git blob. It does not explicitly name or contrast with the nearest sibling (software-support-lookup), so it stops short of 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 phrase 'one exact ... feature and browser' and 'never infer versions' imply this is for precise, single-point data retrieval rather than bulk or inferred queries. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative to route to, leaving usage context inferred.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious context by flagging the call as free and by naming the returned artifacts (input schema, payment configuration), but says nothing about behavior for an unknown or non-paid name.

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, zero waste, and the most decision-relevant fact ('Free:') is front-loaded.

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

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

For a trivial read-only, single-parameter tool with no output schema, the description covers purpose and return contents adequately. It still omits the failure mode for unknown/non-paid names, which an agent needs to plan around.

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

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

Schema description coverage is 0%, so the description must carry the burden; it partly does by implying the single 'name' argument identifies a paid tool. It gives no format, casing, or naming-convention guidance for that 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?

Specific verb (describe) plus resource (one paid tool, its input schema and payment configuration), so the agent knows exactly what it gets back. It implicitly contrasts with the sibling 'list', but never names it, so sibling differentiation is left to inference.

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

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

The leading 'Free:' implies this is the zero-cost inspection step to run before invoking a paid tool, which is useful implied guidance. However, it never states when-not to use it or points to 'list' for enumerating tools, so usage remains inferred.

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 only cover readOnly/openWorld, but the description adds high-value operational context: a per-call price ($0.01 USDC on Base), a hard auth requirement (x402-capable wallet client), and explicit exclusions (no contacts, no certificate details on Workers). These are exactly the behavioral traits structured fields do not 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?

Four tight clauses, front-loaded with the returned data, then exclusions, then cost and auth. No filler, and the highest-value constraints (price, wallet requirement) are stated plainly.

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 by naming the record types returned. It also covers cost, auth, and unavailable data, so an agent has everything needed to decide and invoke 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% and the single 'domain' parameter is fully documented in the schema (public DNS domain, no URL path or contact data). The description's 'One public domain' reinforces the single-domain constraint but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description enumerates exactly what the tool retrieves for a single public domain: sanitized RDAP registration data, DNS A/AAAA/MX/NS/CAA records, and verified HTTPS availability. That is specific enough to distinguish it from every sibling (none of which do domain intelligence), though it leads with a noun phrase rather than an explicit verb.

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

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

Usage is implied by 'One public domain' and the enumerated data categories, so an agent can infer it is for single-domain reconnaissance. However, there is no explicit when-to-use, when-not, or named alternative, and no guidance on batching multiple domains.

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 readOnlyHint/openWorldHint annotations by disclosing the payment model ($0.01 USDC per successful call on Base), the required x402-capable wallet client, the 50-item release cap, and the 90-day window limit. These are exactly the operational facts an agent needs before attempting a call.

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

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

Three tightly packed sentences, each earning its place: capability and limits first, scope exclusions second, cost/auth last. Nothing redundant and nothing buried.

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

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

With no output schema, the description does convey that results are 'summary events' and bounded in count, and it covers cost and auth. It stops short of describing sort order or the fields returned, which would help an agent reason about downstream use, but nothing critical for 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 startDate/endDate semantics, the 1-50 maxItems range, and the minMagnitude bounds. The description's mention of the same limits adds no syntax or format detail 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 (Read) and resource (USGS earthquake summary events) plus hard scope limits: 50 items, 90-day window, optional minimum magnitude. An agent immediately knows what it gets and what it does not get ('no event detail products or contact data').

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

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

Clearly frames the required inputs (an explicit date window) and an optional filter (min magnitude), and explicitly excludes detail/contact data, which tells the agent when this tool is the wrong choice. No named alternatives, but the sibling set is entirely different data domains, so alternatives are not really needed.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses the per-call price ($0.01 USDC on Base), the required x402-capable wallet client, the no-interpolation/no-carry-forward data semantics, and the hard 90-day/50-item caps. Cost and auth requirements are exactly the kind of behavioral 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 core operation and its limits, then data semantics, pricing, and auth. Nearly every sentence carries load, though the pricing/auth sentences could be tightened slightly without losing 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 parameterized read-only range query with no output schema, the definition supplies the constraints, data semantics, cost, and access requirement an agent needs to decide and invoke. The only gap is the shape of the returned rate records, which the description leaves 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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: "Quote units per base unit" clarifies the relationship between the `currency` (quote) and `baseCurrency` (base) parameters, and it reinforces the 50-item/90-day bounds on maxItems and the date range.

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: reading ECB reference or same-day cross rates for one currency pair, with explicit scoping (daily rates, ≤90 days). This is unambiguous. Sibling differentiation is a non-issue since no other sibling tool covers FX data, so it sits just below the top of the scale.

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?

"Reference data, not transaction quotes" gives a useful usage caveat about the nature of the data, and the ≤90-day/≤50-item bounds imply scope. However, it never says when to reach for this tool versus an alternative source or what to do when a range exceeds the limit — usage is implied rather than stated.

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

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

Annotations only cover readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the payment model ($0.01 USDC per successful call on Base) and the client requirement (x402-capable wallet). It also enumerates the returned fields. That is exactly the extra context 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?

Two dense sentences with zero filler: capability and scope first, return fields and cost/auth constraints after. Every clause earns its place, and the most decision-relevant constraint is front-loaded.

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

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

With no output schema, the description compensates by listing the returned fields (IDs, titles, scores, comment counts, links) and by covering the non-obvious cost and wallet prerequisites. 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 are already documented, and the description adds little syntax detail beyond restating the 20-item bound for maxItems. 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?

States a specific verb ('Read') and resource ('Hacker News stories') with explicit scope: up to 20 top stories or a bounded story search. It also carves out what it is not (no users, comments, profiles, hiring text), which cleanly separates it from the sibling news/data tools.

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

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

The description tells the agent how to switch modes ('omit for current top stories' vs. a search phrase) and delimits the content space it will not return. It does not, however, name an alternative tool or state when another source (e.g., arxiv-papers) should be preferred.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context: the call is free and, critically, does not execute or charge a paid tool. That no-cost/no-side-effect guarantee is the key thing an agent must know before poking at paid tooling, and it is stated plainly.

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/listing behavior followed immediately by the non-execution guarantee. No filler and nothing that fails to earn 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?

With no output schema, the description carries the burden of describing returns, and it does name the three things listed (paid tools, input schemas, payment configuration). It stops short of describing the shape or ordering of that output, which is a minor gap for a zero-parameter listing 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, so per the rubric the baseline is 4. The description correctly adds no parameter narrative, since there is nothing to parameterize.

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 supplies a specific verb and resource ('list paid tools, input schemas and payment configuration') that the bare name 'list' and null title cannot, so an agent knows exactly what the tool returns. It does not need sibling differentiation here because none of the listed siblings (arxiv-papers, us-weather-forecast, etc.) is a competing discovery/listing tool.

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

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

Usage is implied rather than stated: the 'Free:' prefix and 'Does not execute or charge' signal this is the safe discovery step before invoking any paid tool. There is no explicit when-to-use/when-not-to-use framing or named alternative, but no plausible alternative exists among the siblings.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing that dependency metadata is capped, which related data categories are deliberately absent, and two critical operational facts: a $0.01 USDC per-successful-call charge on Base and an x402-capable wallet client requirement. These are exactly the constraints an agent must know before attempting a call.

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

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

Three tight sentences: capability and returned fields first, then exclusions, then cost and auth prerequisites. Every clause carries information an agent needs, with no filler or repetition.

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

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

With no output schema, the description compensates by naming the returned fields (latest version, license, publication times, dependency metadata) and the deliberate omissions. The payment and wallet prerequisites are also stated, so nothing required to call it successfully 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 are already fully documented with pattern, default, and maxLength constraints. The description only restates the scoped-name form ('including scoped names') and alludes to the cap ('capped dependency metadata'), adding little beyond the schema; 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 and resource with scope ('Look up one exact npm package') and enumerates the exact payload returned, so the agent knows precisely what this does. It does not explicitly differentiate itself from the closest sibling, pypi-packages, or other lookup tools, leaving that to the agent's inference from the ecosystem 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?

The word 'exact' plus the negative list ('No maintainers, users, contacts, README, tarball or download calls') gives clear when-not context and steers the agent away from expecting those fields. It stops short of naming an alternative tool or stating the condition under which another sibling should be chosen instead.

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 only readOnlyHint and openWorldHint, and the description adds substantial non-obvious behavior: CC0 licensing, deliberate omission of authors/ORCIDs/affiliations, anonymous source allowance, a per-successful-call price of $0.01 USDC on Base, and the x402 wallet requirement. Cost and payment prerequisites are exactly the kind of context an agent cannot infer from 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?

Front-loaded with the core action and result scope, then layered with licensing, payment, and auth constraints in three dense sentences with little waste. 'Anonymous source allowance applies' is vague enough to slightly weaken the structure, but overall it is tight.

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

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

With no output schema, the description usefully enumerates what comes back (metadata, DOI, dates, citations, OA status) and covers cost, licensing, and auth prerequisites. It could say more about result ordering or pagination behavior for a capped search, but 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?

Schema coverage is 100% with both parameters documented ('Work search phrase', the 1-20 range with pattern), so the schema does the heavy lifting. The description restates the cap as 'up to 20' but adds no syntax, format, or query-construction guidance 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 ('Search') plus resource ('OpenAlex works') and enumerates the returned fields (paper metadata, DOI, dates, citation counts, open-access status) with the result cap ('up to 20'). It does not explicitly differentiate from the sibling arxiv-papers, 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?

Usage is only implied by the OpenAlex scope; there is no explicit statement of when to choose this over arxiv-papers or the other paper-adjacent siblings, nor any exclusion criteria. The payment/auth note tells the agent it needs a wallet but not when this source is 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 cover safety (readOnly, openWorld), but the description adds the non-obvious operational facts: it is read-only metadata with no traders or wallet data, costs $0.01 USDC per successful call on Base, and requires an x402-capable wallet client. Cost and payment-client requirements are exactly the kind of behavior an agent cannot infer 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?

Three tight sentences, front-loaded with what is read and how much, followed by data exclusions and then payment/auth constraints. Every sentence earns its place with no redundancy.

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

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

For a two-parameter, no-required-input tool with no output schema, the description covers the data returned, the scoping modes, the privacy boundary, the price, and the client prerequisite. Nothing needed 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 description coverage is 100%, so slug and maxItems are already documented with their formats and defaults. The description restates the slug/active-market split and the 20-item ceiling but adds no syntax or format detail beyond the schema, 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 and resource ('Read ... Polymarket markets') with precise scope: up to 20 active public markets or one exact slug. It also names the returned fields (outcome prices, implied probabilities), so an agent knows exactly what this tool yields and can distinguish it from every sibling in the list.

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 usage modes are explicit: omit the slug for active markets, supply an exact slug for a single market, and the schema reinforces the 24-hour-volume ranking. No competing sibling exists to route against and no when-not guidance is given, which is the only gap.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is already covered. The description adds genuinely useful non-annotation context: a $0.01 USDC per successful call charge on Base, the requirement for an x402-capable wallet client, and that maxItems caps releases and dependency strings at 50. Those are material behavioral facts an agent cannot infer from the schema or annotations.

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

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

Three tight sentences front-load the retrieval scope, then the cap, then the exclusions and price. Every sentence carries information. Slightly dense with the payment details stacked at the end, but no waste.

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

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

For a two-parameter read-only lookup with no output schema, the description covers what is returned, the cap behavior, the exclusions, and the unusual payment/auth prerequisite. Return-field detail compensates for the absent output schema. It could be clearer on exactness requirements for the package name, which is the one 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 coverage is 100%, with both parameters fully described in the schema (PEP 503 normalization, the 1-50 integer pattern). The description repeats the maxItems cap of 50 but adds no format or semantics beyond what the schema already provides, 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?

Specific verb+resource: 'Look up one exact PyPI package, current version, license, Python requirements and recent releases.' The word 'exact' and the pypi-packages name distinguish it cleanly from sibling npm-packages, and the enumerated return fields tell the agent precisely what it gets.

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

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

The description implies when to use it (exact package name lookup) and explicitly excludes PyPI search crawl, maintainers, contacts, long description and downloads. But it never explicitly routes to npm-packages for the JS equivalent or states that a package name is required and must be exact. Implied usage rather than an explicit when/when-not statement.

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 only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the 50-item cap, authentication/config requirement (SEC_USER_AGENT contact), SEC fair-access pacing, a per-call price of $0.01 USDC on Base, and the x402 wallet requirement. This is exactly the kind of side-effect, cost, and rate-limit context the 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?

Four sentences, front-loaded with purpose, followed by exclusions, operational requirements, and pricing. Every sentence carries distinct information; nothing is padded or repetitive.

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

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

Despite having no output schema, the description characterizes the return ('filing index entries', up to 50) and covers the non-obvious operational facts (auth, pacing, payment). An agent has everything needed to decide whether it can and should call this tool.

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

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

Schema coverage is 100%, with form, company and maxItems fully documented in the schema itself. The description restates ticker/CIK and form filtering but adds no format, aliasing, or constraint detail 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 and resource: 'Read up to 50 recent corporate SEC filing index entries by ticker or CIK'. It also scopes what is returned ('index entries') and explicitly excludes filing text, ownership forms and personal filers, so an agent can distinguish it from the sibling paper/document tools 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 scope conditions and negative guidance ('No filing text, ownership forms or personal filers') plus prerequisites (operator-configured SEC_USER_AGENT, x402-capable wallet). It does not name an alternative tool for excluded use cases, so it falls short of a full when/when-not/alternatives routing statement.

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, openWorldHint), yet the description adds genuinely new operational facts: a $0.01 USDC per-successful-call charge on Base, the wallet prerequisite, and the behavior that boolean/unknown EOL values are left unchanged. It still omits failure/payment-failure handling, so not a 5.

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

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

Three dense sentences with no filler: purpose first, then the asOf/computation behavior, then cost and auth. Information is front-loaded and each 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?

With no output schema, the description still conveys the shape of the result (lifecycle dates, source flags, daysToEol), the cost, and the auth prerequisite, and annotations cover the read-only/open-world profile. Nothing essential to calling 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 all three parameters are already documented, and the description's notes on asOf driving daysToEol and on 'exact' release identifiers largely restate 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 ('look up') plus a well-defined resource ('one exact endoflife.date product/release and project lifecycle dates and source flags'), which no sibling tool covers, so it is easily distinguishable. The phrase 'source flags' is slightly opaque, keeping it just below the top mark.

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

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

Usage is implied by the resource (fetch lifecycle data for a product/release) and the prerequisite 'Requires an x402-capable wallet client' is stated, which is useful context. However, it never says when to prefer this over related lookups or what to do if no wallet is available, so guidance is only partial.

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 readOnlyHint/openWorldHint annotations, it discloses the return shape (mapped/unmapped status plus target sequence), an explicit data-scope disclaimer, and crucially the commercial/auth behavior: $0.01 USDC per successful call on Base and an x402-capable wallet requirement. These are exactly the non-obvious operational traits 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?

Four tight sentences, front-loaded with what it does, then return shape, then scope limits, then payment/auth terms. No filler and nothing repeated from the 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?

With no output schema, the description still names the returned fields, and it covers the two things an agent would otherwise get wrong: input scope (single scalar, no personal text) and the paid x402 wallet prerequisite. Nothing material is left unspecified for a 2-parameter lookup.

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

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

Schema description coverage is 100%, so both parameters (codepoint prefix/surrogate rules, unicodeVersion default and response version echo) are already fully documented in the schema. The description restates the single-scalar constraint but adds no syntax or format detail beyond the schema, which is the expected baseline 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 precise verb (look up) and resource (one hexadecimal Unicode scalar) plus the authoritative data source (official UTS #39 confusables). The sibling tools are all unrelated data services, so no sibling differentiation is needed and none is missing.

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

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

The description makes the intended input scope explicit ('one hexadecimal Unicode scalar') and draws negative boundaries ('accepts no personal text', 'makes no identifier-safety judgment'), which tells the agent when this tool is not appropriate. It stops short of naming an alternative tool or an explicit 'use this when...' trigger.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds materially new behavior: a $0.01 USDC per-successful-call price on Base and a required x402-capable wallet client. Billing semantics ('per successful call') and the auth prerequisite are exactly the kind of 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?

Four short sentences, front-loaded with the capability before constraints and pricing; no filler. Slightly dense with mixed concerns (capability, restriction, price, auth) but each sentence earns its place.

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

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

With no output schema, the description usefully lists what comes back (issued time, temperature, winds, precipitation probability) and covers payment/auth constraints. It doesn't specify period granularity (hourly vs. daily) or response shape/pagination, leaving a small gap for a data-returning 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 clarifies the otherwise confusing maxItems parameter by tying it to 'forecast periods' (the schema text oddly mentions 'package tools cap release/dependency metadata'). It also reinforces the decimal coordinate format, adding modest value over 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 (read NWS land forecast periods) plus concrete scope (up to 14, decimal coordinates) and enumerates returned fields. It also draws a boundary against geocoding/address-lookup tools, which no sibling provides, so an agent can route correctly 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 use conditions: only official NWS point and grid forecast URLs, no geocoding or address lookup, and requires an x402-capable wallet client. It doesn't name an alternative sibling tool for cases where the caller lacks a wallet or needs geocoding, so it stops short of full when/when-not/alternatives coverage.

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

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

With annotations only declaring readOnlyHint and openWorldHint, the description adds substantial non-obvious behavior: no JS/browser execution (so script-rendered pages will fail), a mandatory host-approval gate, a $0.01 USDC charge on Base per successful call, and an x402-capable wallet requirement. These are exactly the preconditions an agent needs and are not derivable from annotations or schema.

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

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

Four short sentences, purpose front-loaded, with each subsequent sentence adding a distinct operational constraint (no scripts, approval gate, price, wallet requirement). 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 single-parameter read-only fetch with no output schema, the description covers the safety profile, cost, and access prerequisites well enough to call correctly. It omits output details such as size/page limits and what happens on non-HTML or script-dependent content, which is a modest gap given there is no output schema to lean 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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents that the url must be an absolute HTTPS URL on an approved host with no query strings. The description's 'one document' and 'hosts must be approved' phrasing largely restates that constraint rather than adding syntax or format detail, 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 (convert), a precise resource (one public technical HTML document to Markdown), and draws boundaries (operator-approved, no personal pages). It is clearly distinguishable from the closest sibling, browser-feature-lookup, since it explicitly says no browser or scripts are involved.

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 conditions: one document per call, public technical pages only, no personal pages, and hosts must be approved before use. It stops short of naming an alternative tool for other cases (e.g., where to go for unapproved or personal pages), so it lacks explicit when-not/alternative routing.

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