Saylor Innovations: pay-per-call data

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

Goes well beyond the read-only/idempotent annotations: discloses the $0.02 cost, that payment is USDC on Base, that the response returns POST instructions rather than a paid result, that baselines expire after seven days, and that reads are block-pinned. These are exactly the operational traits an agent needs before invoking 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?

Front-loaded with the core purpose, then constraints, then payment/logistics; every clause carries information. It is dense and the telegraphic final fragments ('USDC on Base. Costs $0.02.') read abruptly, 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?

With no output schema, the description carries the return burden and does so reasonably — 'field-level evidence and unknowns' plus the note that a POST instruction set is returned instead of results. It is complete for invocation; only the exact shape of the evidence/unknowns payload 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%, so the schema already documents address, pool (with its token0()/token1() constraint) and baseline. The description restates the seven-day baseline signing and same-pool pool semantics but adds no format or syntax 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 resource and method: a Base token change report that compares signed seven-day baselines against block-pinned owner, pause, proxy and supply reads. It also names what it deliberately does not do (no honeypot simulation, sell-tax estimate, or safety guarantee), which separates it from check_token_security, though it never names a sibling 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?

Implied workflow is clear — pass a baseline from a previous paid response for the same address/pool to get a change report — and the explicit exclusions ('No honeypot simulation, sell-tax estimate...') tell the agent when not to use it. It stops short of naming the sibling to use instead for those excluded questions, so it is not a full 5.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond that: chain coverage, specific label types returned, LP lock status, creator/owner share, OFAC screening, cost ($0.01), and a free sample URL. It still does not cover auth, rate limits, or error behavior.

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

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

The description is front-loaded with the core capability and then adds the sibling comparison, sample URL, and cost in a tight sequence. It is dense but every sentence adds selection or invocation value, with only minor padding around the sample link.

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

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

For a one-parameter, read-only, paid data lookup with no output schema, the description covers the returned data categories, chain coverage, cost, and a sample. The main gap is the unresolved cross-chain parameter format, but overall it gives an agent enough to decide and attempt a call.

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 describes the parameter as a Solana mint address (base58). The description says the tool works for a token 'on any chain' and lists EVM, Tron, and Sui support, but never explains how to pass a non-Solana contract address or whether the 'mint' parameter accepts them. This creates an unresolved inconsistency that could lead an agent to pass a Solana-formatted value for other chains or vice versa.

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 (holder concentration) and enumerates the exact outputs: Solana top 20 with RugCheck insider labels, EVM/Tron/Sui top holders with contract, locked, burn labels, LP lock, creator/owner share, OFAC screening, and ranked flags. It explicitly distinguishes itself from check_token_security by calling itself deeper than the rolled-up top-10 percentage.

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 the closest sibling, check_token_security, and gives the condition that selects this tool: when you need deeper holder detail than the rolled-up top-10 percentage. It does not explicitly state when not to use it, but the alternative and differentiator are clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds genuinely new information — the per-call cost of $0.01 and the fact that socials are returned alongside the category — but says nothing about what happens for unrecognized tokens or unsupported chains.

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 short clauses: the category enumeration first, then the cost. No filler, and the expensive/surprising detail (price) is placed where it is easy to see.

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 with no output schema, the description covers the category vocabulary, the side output (socials), and the cost, which is enough to call it correctly. Only edge-case behavior for unknown tokens or ambiguous addresses is left unstated.

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

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

Schema coverage is 100%, and the schema already documents the multi-chain address formats and the optional chain override with a full list URL. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description names the resource (a token) and the specific operation — assigning it to one of an enumerated set of narrative categories — and adds that socials come back too. That distinguishes it from siblings like check_token_security or check_token_holders, though it never names a sibling 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?

Usage is only implied: an agent can infer you call this when you need to know what narrative bucket a token belongs to. There is no statement of when to prefer it over get_coin_dossier or compare_tokens, and no prerequisites or exclusions are given.

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 description's job is to add context — and it does: per-call cost, latency character ('fast'), dual independent sources on Solana with the spread reported as a signal. It omits failure modes (unsupported chain, unknown token) and any rate-limit detail beyond the price hint.

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 where each clause carries information the agent needs: chain coverage, Solana dual-source spread, cost, polling use case. Dense em-dash/semicolon packing makes it slightly harder to scan than a two-sentence split would.

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

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

For a 2-parameter read tool with full annotations and no output schema, the description covers what is returned (price, liquidity, spread) and the practical cost/latency tradeoff. Only edge-case behavior — auto-detect conflicts or unsupported mints — is left unaddressed.

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

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

Schema description coverage is 100%, so both `mint` and `chain` are already documented including the optional-chain purpose and a chain list URL. The description's chain enumeration (Solana, EVM, Tron, Sui, TON) largely restates the schema, 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 and resource ('price and liquidity for a token') plus scope ('any chain'), and the 'fast / cheapest / built for polling' framing implicitly separates it from heavier siblings like get_token_snapshot and get_price_history. It stops short of naming an alternative, so an agent must infer the boundary rather than read it.

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?

'Built for polling' and 'Costs $0.01, the cheapest endpoint here' give clear selection context: use this for frequent, low-cost refreshes. No explicit when-not or named alternative is offered, so the agent gets context but not exclusion rules.

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 already covering the read-only/idempotent/open-world profile, this description adds material behavior the agent could not infer: a $0.01 cost, a two-step payment flow (returns payment requirements plus the URL to call once paid), and a free sample endpoint. Disclosing cost and the pay-before-read flow is exactly the kind of context that prevents misfires.

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 dense and front-loaded — the core purpose and the per-chain breakdown come before cost and links. The closing claim that 'an LLM cannot produce this from training data' is promotional filler that does not help an agent invoke the tool, costing some efficiency.

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

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

For a tool with no output schema, the description fully describes the return surface (severity-ranked flags with evidence, verdict, 0-100 score, coverage of what was read) as well as the non-obvious payment handshake. An agent has everything needed to call it and interpret the first 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?

Schema coverage is 100%, so both parameters (mint, chain) are already fully documented upstream, including the 0x/base58 chain-format rules. The description's 'on any chain' phrasing is consistent with the schema but adds no syntax or edge-case detail beyond it, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Token rug risk check') and then breaks down exactly what is checked per chain family (Solana mint/freeze authority, EVM honeypot/tax, Tron/Sui scanner results). It is highly legible on its own, but it never differentiates itself from overlapping siblings such as check_token_holders or base_token_risk_changes, which also surface holder/risk data.

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

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

The rhetorical hook 'is this token safe to buy?' implies the use case, but there is no explicit when-to-use vs when-not guidance and no named alternative among the several token tools (check_token_holders, base_token_risk_changes, get_token_snapshot). The per-chain coverage list gestures at scope but not at tool selection.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the parallel multi-chain read behavior, the cost of $0.01, EIP-7702 delegation detection, and OFAC sanctions screening. These are behavioral traits 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 dense sentence that front-loads the core resource and chains, then lists outputs and closes with cost. Every clause carries information. It is slightly run-on, 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, the description carries the return-value burden and does so by enumerating the report contents (balances, holdings, account type, activity, sanctions, flags) and disclosing cost. An agent knows what it gets and what it pays. Pagination/response format is the only minor omission.

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 chain, tokens and address fully (including the single-chain constraint for tokens). The description's mention of parallel chain reads lightly reinforces the chain parameter but adds no syntax or format detail 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+resource (on-chain wallet profile) and enumerates exactly what is returned: balances, valued holdings, account type, activity, OFAC screening, ranked flags. It clearly conveys multi-chain coverage. However, it never names or contrasts the obvious sibling get_evm_wallet_snapshot, leaving the agent to infer the boundary between them.

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

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

Usage is implied by the enumerated outputs and the disclosed $0.01 cost, which helps a cost-sensitive agent decide. But there is no explicit when-to-use, when-not-to-use, or alternative (e.g. get_evm_wallet_snapshot for EVM-only, cheaper paths) guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld behavior, so the safety profile is covered. The description adds genuinely non-derivable context: the per-mint pricing ($0.0015), the $0.01 minimum total, and the crossover point at which batching beats individual snapshots.

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

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

Three sentences, front-loaded with what is returned, then cost, then use case — every sentence carries information. Minor redundancy in 'Priced per mint at $0.0015 per mint' 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?

Single required parameter, no output schema, and the description names the return contents (scores, verdicts, ranking) plus pricing and range limits. An agent has enough to call it correctly, though the shape of the comparison output is only named, not characterized.

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

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

Schema coverage is 100% and the schema already explains the plain-address vs chain:address convention. The description only restates the 2-10 range and cross-chain support, adding 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?

States a specific verb (compare/side-by-side ranking), the resource (2-10 tokens on any chain), and the deliverable (watchdog scores, verdicts, ranking) in one request. The phrase 'one request' versus 'one call per token' implicitly distinguishes it from the single-token sibling get_token_snapshot.

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

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

Gives concrete usage context: 'Good for screening a watchlist in one call instead of one call per token,' plus a cost-driven rule of thumb (cheaper than separate snapshots at 7+ tokens). No explicit when-not-to-use case, which keeps it just 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 the safety profile (read-only, idempotent, non-destructive, open-world), so the description adds real value on top by disclosing that entity matches are heuristic and must not be treated as proof of ownership or authorization. It also states the $0.01 cost, which is not encoded in 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?

Two sentences plus a short cost statement, front-loaded with the verb and resource. Every clause carries information an agent needs: outputs, caveat, and price.

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 must convey return shape, and it does so at a high level (page metadata, candidate entities, LEI, status) while flagging the reliability caveat. The only meaningful omission for a two-parameter tool is any explanation of what limit controls.

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 50%: the domain parameter is documented in the schema, and the description reinforces that it must be a public company hostname. The limit parameter (default 5, max 20) is described in neither the schema nor the description, so the description does not compensate for the coverage gap.

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

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

The description uses a specific verb ('Resolve') and names the concrete outputs: page metadata plus candidate GLEIF legal entities with LEI and status. It is clear what the tool does, but it does not distinguish itself from the sibling get_page_metadata, which overlaps on the 'page metadata' portion of the return.

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 'leads for due diligence' framing implies the use case, but there is no explicit when-to-use statement, no exclusion of alternatives such as get_page_metadata for plain metadata fetches, and no prerequisites. Usage must be inferred from context.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the description clears the lower bar easily by adding genuinely new facts: SSRF guarding, bounded fetching, pre-payment rejection of private addresses/non-HTML/error pages, and a $0.01 cost. What it omits is truncation behavior when content exceeds max_chars, which matters for a bounded fetch.

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 verb and resource, then behavior and cost. The enumeration of returned fields is dense but earns its place given there is no output schema; nothing is redundant.

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 listing title, author, date, canonical URL, links and metadata. Combined with the SSRF/refusal and pricing disclosure, an agent has enough to invoke it correctly; the only residual gap is max_chars truncation semantics, which the schema range partly covers.

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 67%: url and links are documented in the schema, but max_chars has no description there and the prose does not compensate by explaining truncation or what happens at the 100000-character ceiling. The description adds essentially no parameter-level meaning beyond the schema, so the baseline 3 fits.

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 gives a concrete verb and resource ("Fetch a public URL and extract the main content as clean Markdown") and enumerates the returned fields, so the operation is unmistakable. It does not differentiate from the sibling get_page_metadata, which plausibly overlaps on metadata extraction, leaving the agent to infer the boundary.

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?

"Designed for agent research" implies a usage context, and the refusal conditions (private addresses, non-HTML, error pages) tell the agent what inputs are out of scope. However, no alternative or sibling tool is named, and there is no explicit when-to-use-this-instead-of guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely useful context the annotations lack: a $0.01 cost per call and the caveat that distances are measured from site reference points and are not a property-safety determination. It still says nothing about result caps, pagination, or behavior when both lat/lon and place are supplied.

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 that front-load what is found and where, followed by a cost/limitation sentence where each clause earns its place. Slightly dense packing of the return-field list, but nothing is redundant.

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 outlines the payload contents and warns about distance semantics, which is enough for a zero-required-parameter read tool. The remaining gaps, chiefly radius behavior and what happens when place and lat/lon are both or neither provided, keep it from complete.

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

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

Schema description coverage is only 25% (only 'place' is documented), so the description must carry weight, and it does clarify the two addressing modes ('near coordinates or a place'). However, it never explains radius_km (the actual search band, default 10, capped at 50) or that all four parameters are optional, leaving the most operationally important parameter undocumented.

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 gives a specific verb and resource ('Find U.S. EPA National Priorities List sites near coordinates or a place') and even enumerates the returned fields (identifiers, cleanup status, hazard-ranking score, dates, distance, source profiles), which is well beyond a restatement of the name. It does not contrast itself with any sibling such as get_radon_potential, 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: an agent can infer this is the tool for proximity searches around a point or place name. There is no guidance on when to prefer this over nearby environmental siblings, nor any hint about choosing between the lat/lon and place input modes, both of which are optional and mutually redundant.

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

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

Beyond the annotations, the description adds a per-call cost ($0.01), the data source and its implications, the shape of the return payload (display names, country/region/type, retrieval time, attribution), and precision caveats. That is substantial disclosure for a read-only, idempotent lookup with no output schema.

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

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

Three sentences, front-loaded with the core action, followed by return contents and then limits and cost. Every sentence carries distinct information and nothing is repeated from structured fields.

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

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

For a single-parameter lookup with no output schema, the description supplies what the schema cannot: pricing, data source, return contents, attribution, and accuracy limits. An agent has everything needed to decide to call it and to interpret the result.

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

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

With one parameter at 100% schema description coverage, the schema already defines 'address' fully. The description's phrasing ('street address, place name or landmark') echoes the schema's own description rather than adding new constraint or format guidance, 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?

The description opens with a specific verb and resource ('Resolve a street address, place name or landmark to ranked coordinates') and names the underlying provider (OpenStreetMap Nominatim). No sibling tool performs geocoding, so the absence of explicit sibling routing is not a defect.

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 makes clear when to use it (resolving addresses, place names, or landmarks) and states fitness exclusions: results are not legal boundaries, navigation routes, or survey-grade coordinates. There is no named alternative to route to, which caps this 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?

The annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description adds useful context beyond annotations: the $0.05 cost, a free sample URL, 70+ chain coverage, and the pass/warn/fail rule that unknown is never a pass.

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 value proposition and then lists the returned evidence categories efficiently. It is somewhat long, but the enumeration earns its place for a broad dossier tool.

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

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

With no output schema, the description carries the burden of explaining return content, and it enumerates the major dossier sections plus the verdict checklist. It is nearly complete, though it does not describe response structure or error behavior.

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

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

Schema coverage is 100%, with both mint and optional chain clearly documented in the input schema. The description reinforces that the mint can be on any of 70+ chains but does not add syntax or selection details beyond the schema.

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

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

The description states a specific resource and scope: a complete dossier for one coin across 70+ chains in a single call. It enumerates the included evidence categories, making it distinguishable from narrower sibling token tools such as check_token_security or get_token_snapshot.

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

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

Usage is implied by the comprehensive single-call framing and the $0.05 cost note, but the description does not explicitly say when to choose this over sibling tools or when a narrower check is preferable. No exclusions or alternative-routing guidance are given.

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 and open-world. The description adds genuinely new behavioral information beyond those: a concrete cost of $0.010 and the fact that payment instructions are returned with no provider account needed. It does not say what happens on an unsupported or aggregate code.

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 and reasonably short, but the closing sentence about 'payment instructions for the Saylor endpoint' introduces unexplained jargon that forces the agent to infer what it means, and cost/returned-value statements could be ordered more cleanly.

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 burden of listing returned fields and it does so explicitly; it also discloses pricing. For a one-parameter lookup tool this is nearly complete, with only error/failure behavior left unspecified.

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

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

Schema coverage is 100% and the single parameter already documents the two-letter code format, examples, and exclusion of aggregates. The description only restates 'two-letter country code,' adding no syntax or validation 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 ('Resolve') and resource ('two-letter country code') and enumerates the returned attributes (World Bank name, region, capital, income group, lending classification). It does not distinguish itself from the similar sibling get_economy_report, so it falls short of a 5.

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

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

The phrase 'for data enrichment' implies a usage context, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of how this differs from get_economy_report or get_fx_report, which an agent would plausibly confuse it with.

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 non-destructive traits, so the bar is lower, and the description still adds genuinely non-obvious behavior: a $0.010 cost, a response containing payment instructions for the Saylor endpoint, and no provider account needed. That cost/payment disclosure is the kind of thing an agent cannot infer from structured fields and materially changes invocation planning. It does not describe error or not-found behavior, keeping it short of a 5.

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

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

Three short sentences, front-loaded with purpose and followed by scope limit and cost — each sentence earns its place. Slightly clipped phrasing ("Costs $0.010") reads as terse but stays efficient rather than 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?

With no output schema, the description carries the burden of saying what comes back, and it does so field by field (description, status, CVSS, weakness IDs, references). Cost and payment flow are also covered, which is the main non-obvious operational risk. Only the exact shape of the payment-instruction response 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?

There is a single parameter with 100% schema description coverage including a concrete example (CVE-2021-44228), so the schema already carries the semantics and the baseline is 3. The description adds no constraints beyond the schema, though none are really needed for a single free-form identifier.

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?

Opens with a specific verb+resource ("Resolve a CVE") and enumerates the exact payload: published description, status, CVSS metrics, weakness identifiers, vendor/reference links. That level of field-level specificity makes it distinguishable from siblings like get_package_report or get_python_report 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?

The exclusion "does not scan a system or prove safety" usefully rules out a plausible misreading (that this is a vulnerability scan), which is real when-to-use guidance. It stops short of naming a sibling alternative for adjacent needs, so it is clear context without full routing.

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

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description goes further by disclosing the $0.010 cost, that payment instructions are returned for the Saylor endpoint, and that no provider account is required — non-obvious operational facts an agent must plan around. It omits rate limits, caching/expiry of resolved metadata, and error behavior for unresolvable DOIs, 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?

Three compact sentences, front-loaded with purpose and outputs before scope and cost details; no filler. The cost and payment sentence is genuinely load-bearing rather than decorative. Slightly elliptical phrasing ('Saylor endpoint') is the only mild drag on readability.

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 must characterize the return, and it does — it lists the four categories of data returned and the two excluded categories. It also flags the unusual payment-instruction response path, which an agent would otherwise not anticipate. Missing is what happens on failure or for a nonexistent DOI, a real gap for a paid call.

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

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

There is a single parameter and schema description coverage is 100%, with the schema already stating the identifier format including the optional https://doi.org/ prefix. The description adds no further meaning about the parameter — no accepted DOI forms beyond the schema, no validation or normalization rules. The baseline of 3 applies when the schema fully 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 uses a specific verb and resource ('Resolve a DOI') and enumerates the outputs delivered: normalized publication metadata, citation text, identifiers, and source links. The scope is also bounded by the explicit exclusion of abstracts and full paper text, which makes it distinguishable from siblings like get_papers_report. It stops short of naming an alternative tool by name, which keeps it out of the top band.

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 ('resolve a DOI') but there is no explicit when-to-use or when-not guidance, and no sibling is named as an alternative. The exclusion clause ('Abstracts and full paper text are excluded') clarifies scope rather than routing. The mention of cost and payment is a prerequisite, not a selection 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 and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: a $0.010 cost, that the response includes payment instructions for the Saylor endpoint, and that no provider account is required — billing and auth context an agent would otherwise have to discover by calling.

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 is returned, followed by cost and payment mechanics. No filler, though the payment sentence could be trimmed slightly without losing meaning.

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 compensates by enumerating return contents (years, units, source links, missing values) as well as the payment-instruction payload. For a single-parameter read tool, the only real gap is differentiation from the near-identical sibling get_country_report.

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 coverage is 100%, with the country property already documenting the two-letter World Bank code and the exclusion of aggregates. The description adds nothing about the parameter, 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 plus the exact fields returned (population, GDP in current US dollars, CPI inflation) and the observation limit of five recent annual points. It does not distinguish itself from the sibling get_country_report, which plausibly overlaps, so an agent cannot fully disambiguate from the text alone.

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?

Scope is implied through 'up to five recent annual observations' and the World Bank country-code requirement in the schema, which hints at the use case. However, it never states when to prefer this over get_country_report, get_sdg_indicators or get_fx_report, and gives no exclusions or prerequisites beyond the payment note.

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, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: it returns price and payment instructions, is free, and the agent then pays and receives data. It also clarifies the input is a fully-qualified URL from search_endpoints, adding value beyond annotations without contradicting them.

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

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

The description is two sentences with zero fluff. It front-loads the purpose ('Given an endpoint URL from search_endpoints...'), states the return contents, and adds the 'Free.' note. Every sentence earns its place; it is concise and well-structured.

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

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

The tool is simple (one parameter, no output schema), and the annotations already cover safety and idempotency. The description explains the return content (URL, price, payment instructions), the source of the input, and the overall flow. 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% (the url parameter is fully described as a full https URL including query parameters). The description adds meaning by specifying the URL should come from search_endpoints and have its parameters filled in, which clarifies the expected source and format. This enriches the parameter's semantics beyond the schema.

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

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

The description states a specific verb ('returns'), a clear resource (endpoint price/payment instructions), and a distinct flow: given an endpoint URL from search_endpoints, it provides the exact resource URL, price, and x402 payment instructions. It also mentions 'Free.' to signal cost. This clearly differentiates from search_endpoints (which finds endpoints) and other sibling tools that check tokens or reports.

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

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

The description explicitly says 'Given an endpoint URL from search_endpoints', which establishes the tool's place in the workflow: use after search_endpoints to obtain payment details. It implies the usage context (post-search, pre-payment) and the flow of paying over HTTP. However, it does not explicitly state when not to use it or name alternatives, but the context is clear enough.

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 non-destructive, and the description adds real behavioral context on top: live chain head semantics, the block number returned for reproducibility, and a $0.01 cost that affects invocation decisions. It does not cover failure modes (bad address, unsupported token, RPC error) or whether the cost is incurred on failure.

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

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

Three sentences, each earning its place: capability and chain scope first, return shape second, scope limits and price last. No filler or repetition of the 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?

With no output schema, the description carries return-value disclosure and does so adequately (native balance, ERC-20 balances, metadata, block number). The remaining gap is call-behavior detail — default chain resolution and what happens when a requested token or the wallet itself is invalid — for a modest three-parameter read tool.

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

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

Schema description coverage is 33%, so the description must compensate and does only partly: it names the six chains and ties 'requested ERC-20 balances' to the tokens array. It never states that chain defaults to base, nor clarifies that omitting tokens yields native balance only, leaving the undocumented wallet and chain parameters thin.

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 (a wallet on six named chains) at the live chain head, then enumerates exactly what comes back. Whether it overlaps the sibling get_token_snapshot is disambiguated implicitly by the wallet-vs-token scope, so an agent can pick correctly.

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 'this is a point-in-time read, not custody, valuation, proof of reserves or transaction authorization' clause gives concrete when-not-to-use boundaries that no sibling covers. It stops short of naming an alternative tool for those other needs, so it is a strong 4 rather than 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 semantics, but the description adds genuinely new behavioral context: a $0.01 cost, x402 payment instructions in the response, source provenance, and explicit execution-risk warnings. The only shortfall is that it does not resolve whether a call returns actual rate data or just payment instructions, which leaves a meaningful call-outcome ambiguity.

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 response content is front-loaded in the first sentence, with cost/payment information second, which reflects the right priority order. The feature list is dense and slightly catalog-like, but every clause carries 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?

With no output schema, the description does the work of describing return content (rates, intervals, annualized figures, spread signals, provenance, risk warnings), which is substantial. The remaining gap is the paid-endpoint mechanics: an agent cannot tell from the definition whether a successful call yields usable data or a payment handshake.

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 carries the full burden. It hints at two of the three parameters indirectly — 'open interest filters' maps to minOiUsd and 'spread/arbitrage signals'/'annualized comparisons' map to the spread/apr sort enum — but it never names them or explains defaults, and the limit parameter has no coverage anywhere.

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

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

The description names a specific resource (perpetual-futures funding rates) and enumerates the covered venues (Hyperliquid, Binance, Bybit), plus the derived content it returns: venue intervals, annualized comparisons, spread/arbitrage signals. No sibling tool in the list deals with funding rates, so an agent can immediately distinguish it from get_price_history, get_stock_quote, or get_token_snapshot.

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

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

Usage is only implied: the mention of open-interest filters and spread/arbitrage signals suggests it is the tool for cross-venue funding comparison, but there is no explicit when-to-use statement, no when-not guidance, and no named alternative among the 39 siblings. An agent must infer the trigger conditions from the feature list.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description goes beyond them by disclosing the data source (ECB), the fact that no provider account is required, the $0.010 cost, and that responses include payment instructions for the Saylor endpoint. The monetization/payment handshake is behavior an agent cannot infer from schema or annotations.

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

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

The core purpose is front-loaded in the first sentence, followed by caveats in descending importance (not trading quotes, free alternative, cost, payment mechanics). Terse and mostly waste-free, though the ECB-alternative sentence is peripheral to invocation.

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

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

With one documented parameter and no output schema, the description carries the burden of explaining returns and it does so (rates per unit of base, observation date, currency codes, payment instructions). Cost, sourcing, and account requirements are all disclosed, leaving little an agent needs that 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 the single 'base' parameter is fully documented with format and examples, so the baseline is 3. The description adds only marginal meaning by clarifying that rates are quoted per one unit of the base currency, which frames the output rather than the parameter itself.

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: daily reference exchange rates per one unit of a base currency, including the fields returned (observation date, currency codes). It also disambiguates from trading-quote tools with 'Not executable trading quotes', though it never names a sibling 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?

Usage is implied rather than stated: the 'not executable trading quotes' clause tells the agent what this tool should not be used for, which is genuinely useful routing guidance. However, no positive when-to-use condition or named alternative (e.g. get_stock_quote, get_funding_rates) is given.

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, and destructiveHint false, so the tool is known to be safe and non-mutating. The description adds substantial behavioral detail: free guides return the full body immediately, paid guides return payment requirements (a URL) instead of the body, and a PAYMENT-SIGNATURE header is needed to complete payment. It also specifies the cost and payment networks. This goes far beyond the annotations and is crucial for correct invocation.

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

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

The description is three sentences with zero wasted words. The core purpose is front-loaded ('Fetch a guide by id'), followed by the free/paid distinction and payment flow. Every sentence adds essential information, and the structure is logical and scannable.

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

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

Given there is no output schema, the description fully explains what the tool returns in both cases (free vs paid), including the payment completion step. It covers the cost, payment methods, and the required header, which is all an agent needs to correctly invoke the tool and handle the result. 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?

There is only one parameter, 'id', and the schema already describes it as 'Guide id, from search_guides' with 100% coverage. The description repeats the purpose ('by id') but adds no new format, syntax, or constraints beyond the schema. Baseline of 3 is appropriate since the schema fully documents the parameter.

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

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

The description states a specific verb ('Fetch') and resource ('a guide by id'), clearly distinguishing it from search_guides which finds guides. It also clarifies the free vs paid distinction, so an agent knows exactly what this tool does and how it differs from siblings.

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

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

The description implies usage: use this when you have a guide id (from search_guides, as noted in the schema). It provides clear context about free vs paid behavior and how to complete payment, but it does not explicitly state exclusions or name alternatives like 'use search_guides to find guides first.' Still, the context is clear enough for correct selection.

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

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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: a stated cost of $0.010, that payment instructions are returned, and that no provider account is required. It still omits failure modes or what happens if payment is not completed.

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

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

Two sentences, front-loaded with what is returned and its limit, with the commercial terms appended. Nothing is redundant, though 'the Saylor endpoint' is an unexplained internal name that costs a few words of clarity.

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

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

With one parameter, no output schema, and no nested objects, the description does the necessary work: it describes the shape of the result set (up to five packages with named fields) and the non-obvious payment flow. A brief note on error or empty-result behavior would close the 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?

There is a single parameter with 100% schema description coverage ('Search terms, 2–160 characters'), so the schema already carries the constraint. The description adds no syntax, quoting, or scoping hints beyond the schema baseline.

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

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

States a specific verb and resource ('Find npm packages') and enumerates the returned fields (versions, descriptions, ranking scores, source links) plus a result cap of five. It does not differentiate itself from the close sibling get_package_report, which an agent must still disambiguate on its own.

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

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

The phrase 'for package discovery' implies a discovery use case, but there is no explicit when-to-use or when-not-to-use guidance, and no routing between this tool and get_package_report or verify_repository. Usage is inferable 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?

The annotations already declare readOnly, idempotent, non-destructive and open-world behavior, but the description adds genuinely new facts: no package code is downloaded or executed, the call costs $0.010, and the response returns payment instructions for the Saylor endpoint with no provider account required. The payment and pricing flow is important behavioral disclosure that annotations cannot convey. It stops short of describing failure modes or per-call versus per-session billing, which keeps it from a 5.

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

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

Three sentences, each carrying distinct information, with the capability statement front-loaded and the cost and boundary conditions following. The first sentence is a dense list but every listed field is useful signal; nothing repeats the schema or the annotations.

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 the result, and it enumerates the returned fields well and explains the payment flow. Minor gaps remain: it does not say which dist-tag is treated as 'latest', how errors or missing packages are reported, or whether the $0.010 is charged per 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?

There is only one parameter and schema description coverage is 100%, with the schema itself explaining that '@scope/name' is allowed. The description adds no additional meaning about the name parameter, 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 gives a specific verb and resource ('Inspect the latest npm package release') and enumerates the exact fields returned (version, license, dependency counts, engine requirements, deprecation notice, source links). It does not explicitly differentiate itself from nearby siblings such as get_npmsearch_report or verify_repository, so an agent must infer the boundary from the field list alone.

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

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

There is no explicit when-to-use versus when-to-use-an-alternative guidance and no named sibling. The clause 'Does not download or execute package code' implies a metadata-only inspection scenario, which implicitly frames usage, but the agent is left to infer that a search-oriented sibling exists for discovery-type needs.

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, so the safety profile is covered. The description adds genuinely new behavioral facts: SSRF guarding (internal targets are rejected), that the full body is NOT returned (bounding response size/expectations), and a per-call price of $0.01. It does not say how missing or malformed metadata is handled, but the disclosure exceeds the annotation baseline.

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

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

Three short sentences, front-loaded with the returned fields (the most decision-relevant information), followed by the SSRF/no-body constraint and the cost. Nothing is redundant and no sentence could be dropped without losing a fact.

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 correctly compensates by enumerating the returned metadata fields, and it pairs that with the SSRF guard and pricing. Remaining gaps are modest: no statement about behavior when fields are absent, redirects, or non-HTML content types, which matter for a single-URL fetch 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?

Only one parameter with 100% schema description coverage (format uri, pattern ^https?://, 'Public HTTP(S) page URL.'), so the schema already carries the semantics and a baseline 3 applies. The description's mention of 'public' reinforces the SSRF-relevant restriction but adds no syntax, normalization, or redirect-following 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 concrete verb and resource (extract metadata) and enumerates the exact fields returned — title, description, OG image/site name, author, publication date, canonical URL, language — plus the constraint to public HTTP(S) pages. It stops short of distinguishing itself from the sibling extract_webpage_markdown, which also operates on a web page URL, so an agent must infer that this one returns structured fields rather than body text.

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 'public HTTP(S) page' implicitly excludes internal/authenticated URLs, and the stated $0.01 cost supports a cost/benefit decision before calling. However, there is no explicit 'use this when you need fields X instead of the full content' routing against extract_webpage_markdown, which is the obvious near-neighbor in the sibling list.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's added value is real: it discloses a $0.010 cost, a payment-instruction/pay-per-call flow, and that no provider account is needed. Those are non-obvious preconditions an agent must know before calling. It stops short of explaining what happens on payment failure or whether the five-result cap is configurable.

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 is returned before the caveats and cost. Every sentence carries information, though the phrase "the Saylor endpoint" is unexplained jargon that costs a little clarity.

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 correctly compensates by naming the fields returned and explicitly excluding abstracts/full text. The cost and payment model are disclosed. Minor gaps remain: result ordering/relevance, and what a successful versus unpaid response looks like, are not described.

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

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

There is a single parameter with 100% schema description coverage, including the 2–160 character constraint, so the schema already carries the semantics. The description adds nothing about query syntax, matching behaviour, or how to phrase terms for good recall; baseline 3 applies when the schema does the work.

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

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

The description uses a specific verb+resource ("Find up to five publications") and enumerates the returned fields (DOI, authors, year, citation counts), which lets an agent recognise this as a literature-search tool rather than a lookup. It does not, however, explicitly distinguish itself from the nearby sibling get_doi_report, whose name suggests overlapping DOI work.

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

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

Usage is only implied: the agent can infer this is for keyword literature search and that it returns metadata rather than full text, which is a useful boundary. There is no explicit when-to-use statement, no mention of when to prefer get_doi_report or verify_repository, and no guidance on result limits or query scope beyond the hard cap of five.

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, so the safety profile is covered. The description adds genuinely new context: the data is sourced from the token's deepest pool (a selection behavior the agent could not infer), volumes/derived metrics are computed from the candles, and each call costs $0.01. Return format details (pagination, candle shape) remain unstated.

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

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

One dense sentence front-loads the resource and its distinguishing property, followed by a brief positioning clause and a terse cost note. No filler, no repetition of schema fields.

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 explaining returns and does so by naming the candle data and the four derived metrics. Combined with full parameter coverage in the schema and complete annotations, an agent has enough to invoke it correctly; only the concrete response/pagination shape is left unspecified.

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

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

Schema description coverage is 100%, with each parameter documented including enum and defaults, so the schema carries the load and 3 is the baseline. The description adds only the 'deepest pool' sourcing note, which is more behavioral than parameter-specific; it adds no syntax or format 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+resource ('OHLCV candles for a token on any chain') and enumerates the derived metrics returned. It explicitly positions itself against the rest of the catalog ('the only time-series data in this catalog; every other endpoint is a point-in-time snapshot'), so an agent can separate it from check_token_price and get_token_snapshot 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 time-series framing gives clear context for when to reach for this tool versus the point-in-time snapshot endpoints. It also surfaces a cost signal ($0.01), which is a practical selection factor. There is no explicit exclusion or named sibling 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 already cover safety (readOnly, idempotent, non-destructive), yet the description adds genuinely new behavior: no code execution, a $0.010 cost, payment-instruction return flow, and no provider account needed. The one weakness is ambiguity about whether this call returns report data or only payment instructions, but the disclosure of cost and auth requirements is well beyond annotation coverage.

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

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

Three short sentences, front-loaded with what is inspected before the operational notes. Nearly every clause earns its place, though the phrase 'the Saylor endpoint' is unexplained jargon that costs a little clarity.

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 the work of listing the returned content categories and the payment/auth model, which is adequate for a one-parameter read tool. The residual gap is whether the response is data or a payment handoff, which an agent would want resolved 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?

There is a single parameter with 100% schema description coverage ('Public Python package name'), so the schema already carries the semantics. The description only restates 'Python package' and adds no syntax, format, or edge-case detail (e.g., case sensitivity, normalization, PyPI vs. import name).

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?

Opens with a specific verb ('Inspect') and a precisely scoped resource ('a Python package's latest release'), then enumerates the inspected facets: compatibility, dependencies, license, advisories. The 'Python package' qualifier implicitly separates it from the npm and generic package-report siblings in the same namespace.

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 enumerated facets, so an agent can infer this is the tool for Python package due diligence, and the pricing note signals a paid call. However, there is no explicit when-to-use/when-not guidance and no sibling is named (e.g., get_npmsearch_report or get_package_report as the non-Python 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, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: a $0.01 cost per call and an interpretive caveat that the value is area-level, not a home-specific measurement and does not substitute for testing. It stops short of describing error behavior for unresolved places or out-of-U.S. coordinates.

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

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

Two sentences, both load-bearing, with the primary purpose front-loaded and the cost plus the most common misconception (area-level vs. building measurement) placed immediately after. No filler or repetition of the 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 simple read-only lookup with no output schema, the description enumerates the returned concepts (index, province, geology, screening guidance) plus cost, which is close to sufficient. The remaining gap is input resolution — whether a free-text `place` is geocoded internally and what happens when it cannot be resolved.

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 only 33%: only `place` carries a description, while lat and lon are bare numbers with bounds. The description compensates partially by establishing that the target must be a U.S. location, but it does not state the precedence between `place` and lat/lon, nor that all three are optional (0 required) and at least one is presumably needed.

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?

"Look up area-level geologic radon potential, index, province, geology and EPA screening guidance" names a specific verb, resource, and the concrete fields returned, scoped to a "U.S. location." No sibling tool (find_superfund_sites, get_snowpack) overlaps, so an agent can select it unambiguously.

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

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

The description clarifies the applicable domain (a U.S. location) and explicitly warns it is "not a building measurement," which is a useful scope caveat. However, it names no alternatives and gives no routing guidance — e.g., whether to call geocode_address first when only a street address is available, or what to do outside the U.S.

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, so the safety profile is covered. The description adds genuinely non-structured context: the $0.01 cost and the fact that results are seconds-to-minutes-old and decay quickly, which affects how an agent should treat and re-fetch the 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?

Two compact sentences with the scope and default chain front-loaded, then the payload contents and price. The middle fragment ('Age, liquidity, buy/sell flow and conservative risk flags') is list-like but earns its place as a return-value summary.

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 the returned fields and discloses cost and data volatility. The remaining gap is result-set size or pagination behavior — an agent cannot tell how many pools come back or whether a cap applies.

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 chain, minLiquidity and maxAgeMinutes. The description restates the chain default ('Solana (default) ... via chain') but adds no syntax, units or interaction details beyond that, making 3 the appropriate 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 the resource precisely: brand-new token pools, default Solana with a chain override, and signals freshness ('seconds to minutes old'). This distinguishes it in spirit from get_trending_pools, but never names that sibling, so the agent must infer the boundary rather than being told it.

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 'the most perishable data here' hints at when this tool is the right pick (recency-sensitive queries) and the default chain is stated, but there is no explicit when-not condition and no named alternative for established or trending pools.

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 real context beyond them: the returned fields, earliest comparison values, source provenance, the caveat that reporting years vary by indicator, and a $0.01 cost that affects invocation decisions. It still omits coverage breadth, such as how many indicators or goals are returned.

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 front-loaded sentence with no filler; the payload enumeration is dense but each element informs the agent what it will receive. The cost clause and year-variance caveat are appended efficiently.

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, describing the return shape (series, values, years, units, comparisons, provenance) is exactly what the description should do, and it adds the two facts an agent most needs before calling: variable reporting years and a per-call cost.

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 (code, goal) are documented in the schema with pattern and range. The description adds no additional meaning about how code or goal affect the response, 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 ('Return latest reported headline UN SDG indicators for a country') with the content scope spelled out. It does not name or distinguish itself from plausible siblings such as get_country_report or get_economy_report, so an agent must infer the boundary.

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 phrases like 'latest reported headline' indicators; there is no explicit when-to-use or when-not-to-use statement and no routing to alternative tools.

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

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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description earns credit for two things annotations cannot convey: the per-call cost and the geographic coverage limit that determines failure. It does not state what happens when no station is within radius or how results are ordered.

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

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

Two sentences, no filler, with the return fields front-loaded and the constraints (cost, coverage) trailing. Every clause carries information an agent would otherwise have to infer.

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 output contract is fully covered by the enumerated return fields, and cost/coverage are stated. However, with 5 parameters, zero required fields, and 20% schema coverage, the description leaves a genuine ambiguity unresolved: whether lat/lon or place must be supplied, and how limit/radius_km shape results. That is a meaningful gap for a paid call.

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 only 20% (only `place` is documented), so the description must carry the parameter burden and does not. It never explains lat/lon ranges, the limit cap of 10 stations, or that radius_km (default 100, max 300) defines "nearby"; the word "nearby" and the output field "distance" only loosely imply the radius concept.

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?

Uses a specific verb+resource ("Find nearby USDA NRCS SNOTEL stations") and enumerates exactly what comes back: snow-water equivalent, snow depth, water-year precipitation, temperature, distance, observation date, percent-of-median. No sibling tool covers snowpack, so it is trivially distinguishable from the token/web/geo siblings 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?

Adds a real usage boundary: "coverage is mountainous western U.S. and Alaska," which tells an agent when not to bother calling, plus a cost signal ($0.01). It stops short of naming alternatives or explaining when to prefer lat/lon over the place parameter, so it falls one step below fully explicit routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is free. Beyond that the description discloses real behavior: Yahoo Finance primary with a Nasdaq fallback, possible exchange delays, unknown symbols returning a 404 without charge, and a $0.01 cost — material context an agent could not get from the annotations. It stops short of covering auth or pagination, 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?

Two tight sentences, front-loaded with what is returned, then the operational caveats. Every clause (fallback provider, delays, 404 behavior, price) carries distinct information, though the telegraphic semicolon phrasing is slightly terse.

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

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

For a one-parameter read-only tool with no output schema, the description names the returned fields, the data source, the latency caveat, error semantics for bad symbols, and cost — enough to call it confidently. Only the exact response shape and whether the 404 is distinguishable from other errors are left unstated.

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

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

There is a single required parameter and schema description coverage is 100%, with the schema itself providing ticker examples (AAPL, SPY, ^GSPC). The description adds no format, casing, or symbol-resolution detail beyond that, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ("Look up a stock, ETF or index quote") and enumerates the returned fields, so an agent immediately knows this is a live equities quote. The asset-class framing (stock/ETF/index) implicitly separates it from token-price siblings like check_token_price and get_token_snapshot, but no sibling is named explicitly, so a 4 rather than 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: the word "quote" and the mention of a market timestamp signal a current snapshot, which contrasts with get_price_history, but the description never states when to prefer this over that or over get_fx_report. It does supply operational guidance (provider fallback, delays, cost), which is useful but is not when-to-use routing.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely useful non-schema behavior: a metered cost of $0.01 and the inclusion of derived outputs (verdict, scores, data coverage) that signal the response is a synthesized report rather than raw fields. It does not discuss rate limits or response size for what is clearly a large 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?

One front-loaded sentence with the resource and the 'in one call' framing first, then the payload list, then the price. The field enumeration is long but each item carries selection value; nothing is redundant.

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 correctly discharges the burden of telling the agent what comes back, listing all major sections plus a verdict and data-coverage signal. Combined with fully documented parameters and safe-read annotations, only minor gaps remain (payload size, latency, failure modes).

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

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

Schema coverage is 100%, and the schema already explains base58/0x/coin-type formats and the chain auto-detect default, so a baseline of 3 applies. The description reinforces 'on any chain' but adds no format or disambiguation detail beyond the schema.

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

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

The description names a concrete resource (a full token snapshot across any chain) and enumerates the exact payload: price, liquidity, holders, pairs, socials, security flags, scores, verdict, price-impact, coverage. The phrase 'in one call' implicitly separates it from narrow siblings like check_token_price or check_token_security, though it never names them outright.

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 reader can infer this is the aggregate route when multiple data facets are needed, and the explicit $0.01 cost helps with cost/benefit decisions versus cheaper single-purpose siblings. However, there is no explicit when-to-use or when-not-to-use statement and no sibling is named as an alternative, so 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 readonly/idempotent/non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the returned dataset (price, liquidity, volume, 24h change) and a per-call cost of $0.01, which is actionable for an agent deciding whether to invoke it.

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 tight sentence with zero waste: resource and default scope first, then returned fields, then cost. Everything 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 read-only list tool with no output schema, the description covers scope, default chain, the fields returned, and the cost, while the schema fully documents both optional params and annotations cover safety. 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 both parameters are already documented ('chain' id and default, 'limit' max 50). The description only reiterates the chain default, adding no format or syntax detail 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+resource ('currently trending token pools') plus the chain scope and the data fields returned (price, liquidity, volume, 24h change). It is clearly a discovery/list tool, distinct from price-checking or snapshot siblings, though it does not explicitly contrast itself with near neighbors like get_recent_launches or get_token_snapshot.

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

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

Usage is implied ('default Solana or any supported chain via chain'), giving enough to invoke correctly, but there is no explicit when-to-use versus alternatives or when-not-to-use guidance relative to the many token siblings.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond those: it is free (cost/rate implication) and returns the complete result in a single call ('One call reveals the whole shape'), which implies no pagination or partial results. No contradiction with annotations.

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

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

Two short sentences with zero filler. The resource and scope come first, then the behavioral notes. Every clause adds distinct information: catalog scope, counts, cost, and one-call completeness.

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, idempotent list operation, the description plus annotations fully equip an agent to call it. No output schema exists, but the simple return (categories and tags with counts) is adequately implied. 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?

The tool has zero parameters, and schema coverage is trivially 100%. The baseline for 0-param tools is 4, and the description correctly emphasizes that no input is needed ('One call reveals the whole shape'). No parameter-level detail 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 states a specific resource ('Every category and tag in the catalog') and adds the outcome (counts, full shape). It is unambiguous about what this tool returns. It does not name sibling tools or contrast itself, but the resource is distinct enough among siblings like list_bot_rentals and list_data_endpoints.

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

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

Usage context is implied by 'One call reveals the whole shape' — an agent can infer this is the go-to tool for exploring the catalog taxonomy. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives, leaving routing 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, openWorld and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: the operation is free, it reflects the live manifest, and it returns the complete set (no filtering). Pagination/result-size behavior is not addressed.

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 compact sentences, front-loaded with what is returned, then the cost and usage cue. 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 compensates by listing the returned fields (description, price, networks, discovery links) and framing the tool as the catalog entry point. Nothing essential to 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the schema. Baseline for a no-param tool 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 (list) and resource (currently buyable endpoints in the live x402 manifest), and enumerates the payload contents: description, price, payment networks and discovery links. This is distinguishable from siblings like get_endpoint (single) and search_endpoints (filtered query).

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 tells the agent to call this first to see the complete catalog, and notes it is free, giving clear entry-point context. It stops short of naming an alternative (e.g. search_endpoints) or stating 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 declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context: cost (free), auth requirements (x402, no account/key), and return fields plus the next step, though it omits pagination and rate limits.

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

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

Front-loads purpose and return information, but the middle catalog list is very long. While each domain adds coverage detail, the list could be trimmed without losing the core message.

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 explains exactly what is returned (url, example call, sample response URL, price, description) and the next step (get_endpoint). Annotations cover safety, so the definition is complete for a search 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 50%: the 'query' parameter is documented in the schema, but 'limit' is not. The description's long list of domains indirectly hints at query content but adds no syntax or limit guidance, so it does not compensate for the gap.

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

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

States a specific verb (Search) and resource (Saylor catalog of pay-per-call data endpoints), and distinguishes itself from get_endpoint by noting the follow-up call. The catalog listing makes the scope 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?

Describes its role in the workflow ('then call get_endpoint for payment details'), but does not explicitly compare to sibling list_data_endpoints or list_categories, leaving the agent to infer when to search versus list all.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-derivable behavior: per-query cost ($0.01), variability in source coverage, and multilingual filing, which together warn that results may be incomplete or in a non-English language and that calls are metered. Missing only pagination/total-count behavior and whether results are deduplicated.

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

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

Two sentences, front-loaded with what the tool is and what it returns, then a compact caveat block covering audience, coverage, language and cost. Nothing is redundant with the title, and the closing price note is one short clause rather than a 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?

With no output schema, the description correctly compensates by enumerating returned fields, and it discloses cost and coverage caveats for a live external database. The remaining gap is scale behavior: with limit capped at 20 there is no statement about whether more results exist or how to page, which matters for an open-world search.

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 67%: `q` and `country` carry their own descriptions and examples, while `limit` is self-documenting via default 10 and bounds 1-20. The description adds no parameter-level meaning at all — it never mentions country filtering, the 20-result cap, or whether `q` supports operators versus plain full text. That matches the baseline 3 where 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?

"Search current notices in TED, the EU official procurement database" gives a specific verb (search) plus resource (TED notices), and immediately enumerates what comes back (buyer, title, description, CPV codes, publication date, deadline, source link). No sibling tool in this list touches procurement, so there is no ambiguity to resolve, but the scope is still stated precisely enough that an agent knows exactly what corpus is being queried.

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 "Useful for sales-lead and market-intelligence agents" implies the use case, and the note that "source coverage and filing language vary" hints at limits on recall. However, there is no explicit when-to-use vs when-not, no mention of an alternative tool for non-EU procurement, and no guidance on when results would be sparse or when to re-query. Usage is inferable but not directed.

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 idempotentHint=true, so the read-only safety profile is covered. The description adds valuable behavioral context beyond that: the guides are free ('no payment') and the operation returns only metadata, never bodies. These details help an agent set expectations without contradicting 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 short sentences with no fluff. Purpose is front-loaded, followed by cost and return-type constraints. Every 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?

The description covers purpose, cost, and the metadata-only return constraint, and annotations cover safety. However, with no output schema, the description does not detail what metadata fields are returned or how results are paginated. For a tool with 5 optional parameters, this leaves some room for agent uncertainty about the exact response 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 60%, so the schema documents tag, query, and free_only but leaves limit and category underdocumented. The description adds some indirect parameter context by listing topic areas (which map to categories) and mentioning 'Free — no payment' (relating to free_only), but it doesn't systematically explain parameters. This is adequate but not a strong compensation for the coverage gap.

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

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

Description states the specific verb 'Search' plus the resource 'Saylor Innovations technical guides' and lists topic areas. It further distinguishes itself from siblings like get_guide by explicitly saying 'Returns metadata only, never bodies.'

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

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

The description implies the use case—finding technical guides before retrieving them—and the 'never bodies' line hints at a boundary with get_guide. However, it never explicitly says 'use this to discover guides, then call get_guide for full content' or names any alternative. No clear when-not-to-use guidance is provided.

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, idempotentHint, and destructiveHint false; the description adds context that the tool clones into a disposable environment (non-persistent), runs only declared scripts, and charges $0.25 per attempt. It discloses cost and the limitation on semantic correctness, which go beyond annotations. No contradiction is present.

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

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

The description is three sentences with no fluff. It front-loads the core action, then states exclusions and cost. Every sentence adds essential information, and the structure is scannable.

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

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

Given there is no output schema, the description explains what is returned: 'structured logs plus the resolved commit' and 'the paid HTTP endpoint and x402 instructions.' It covers the core behavior, limitations, and cost. It could mention timeout behavior or error handling, but for an agent to decide whether to invoke, it is sufficiently complete.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description adds that the task is a 'declared test, lint, or build script' and that it runs in a microVM, which reinforces the task and repository semantics. However, it does not clarify ref, timeoutSeconds, or packageManager beyond the schema. The baseline of 3 is appropriate.

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

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

The description uses specific verbs and resources: 'Clone a public GitHub repository into a disposable Firecracker microVM, install dependencies, run one declared test, lint, or build script, and return structured logs plus the resolved commit.' It clearly defines the action and output, and distinguishes from sibling tools focused on tokens, wallets, and reports. The clarification 'verifies execution, not semantic correctness' further sharpens the purpose.

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

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

The description explicitly states exclusions: 'private repositories and arbitrary shell commands are not accepted,' and implies the scope of use (public repo verification). It does not name alternative tools, but the sibling set makes the uniqueness obvious. It also mentions the cost and payment endpoint, which guides whether to use it.

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