Aayat AI

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

Annotations already cover readOnly/openWorld/idempotent, so the bar is lower; the description still adds valuable context by disclosing the costly-call mechanism ($0.003 in USDC per call, x402 or prepaid credits) and that it is a live-data (non-cached) catalog. It does not mention rate limits or result-size 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?

Effectively two content-bearing sentences that front-load the catalog scope and returned fields before the payment terms. Dense but every clause earns its place; the 'Filter by Price: $0.003' phrasing is slightly garbled but brief.

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 an output schema present, annotations, and 8 fully-documented params, the description only needs to establish scope, coverage breadth, returned fields, and the payment gate — all of which it does. The remaining gap is sibling routing against ai-models-pick.

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 params are fully documented structurally; the description only restates the filter concepts (price, provider, features, context length) without adding syntax, defaults, or interaction rules. 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 (live prices and specs of 400+ AI models) and enumerates exactly what is returned: input/output token prices, cached-input price, context length, max output, and capability flags. It does not name or differentiate itself from the sibling ai-models-pick, which is the one thing an agent needs to disambiguate.

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

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

Usage is implied by the filter/field enumeration (browse and compare models by price, provider, features), and the payment line conveys the access model. But it never states when to choose this over ai-models-pick or chat/embeddings siblings, nor any when-not conditions.

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

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

Annotations cover the read-only/idempotency profile, and the description adds valuable context beyond them: live prices, output units (USD per call and per 1,000 calls), a paid-call price ($0.01 USDC via x402/prepaid) and a free-trial flag. It does not, however, explain ranking direction or the fallback behaviour when no suitable model exists.

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

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

Dense but front-loaded: opening sentence states the core promise, then inputs, then outputs, then billing. Every sentence carries information; the only mild bloat is repeating the price twice (per-call and free-trial mention in one clause).

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 nine optional parameters, an output schema (so return values need no description) and rich input schema, the description is appropriately complete: it covers inputs, cost outputs and the payment channel. It leaves minor gaps — ranking behaviour and handling of no-match results — but nothing that blocks correct invocation.

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

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

Schema coverage is 100%, so the schema documents all nine parameters with defaults, maxes and enums. The description reinforces the intent of the task/quality inputs but adds no syntax or format detail beyond what the schema already provides (e.g. it doesn't specify tie-breaking or how the AI infers features from a task string).

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 (pick) and resource (cheapest suitable AI model), explains exactly what the agent gets back (cheapest suitable models across major providers with per-call and per-1k-call cost), and its primary differentiator vs the rest of the catalog is the cost-optimisation objective.

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

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

Gives clear context on when to use it — you need to pick a model for a task and want the cheapest one — and offers two input styles (describe a task, or enumerate features). It does not, however, name a sibling alternative (e.g. ai-models) or state when NOT to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing the context-dependent behavior (credits key in the URL switches the response) and that the call is free.

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 with the primary outcome front-loaded and the conditional secondary mode placed after. Slightly dense parenthetical, but every clause earns its place.

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

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

With no parameters, no output schema and a safety profile already in annotations, the description supplies the one thing an agent needs: what two shapes the answer can take and what determines which. Adequate for a zero-input 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?

Zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly adds no fake parameter detail, only clarifying that the server URL carries the credits key.

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 (shows) and resource (prepaid credits balance / free-trial calls), and even enumerates the two distinct return modes. It does not, however, differentiate itself from the sibling get_credits, which an agent could easily confuse it with.

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

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

The description gives a conditional clue — 'when this server's URL carries your credits key' — which implies when each mode applies. But it never names an alternative tool or states when NOT to use this versus get_credits, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true/openWorldHint=true, so safety is covered; the description adds genuinely useful behavior beyond that: newest-first ordering, breaking-line flagging, cross-ecosystem and GitHub-repo coverage, and the pricing/trial terms ($0.005 USDC via x402 or prepaid, free trial). It stops short of 5 by not noting limits such as the 'up to 2 years back' window that only appears in the schema.

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

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

A single dense paragraph that front-loads the core capability before pricing and scope caveats. Every clause carries information, though the pricing/trial sentence could arguably be trimmed for an agent whose schema already implies commercial context.

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

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

An output schema exists, so return format needn't be explained, and annotations carry the safety profile. The description supplies the remaining essentials: sources, ordering, breaking-change flagging, GitHub fallback, and cost, making it complete for an agent to select and invoke it.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the ecosystem list and the name-vs-repo dual input mode, but adds no format, syntax, or default guidance beyond what the schema's property descriptions already supply.

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: what changed in a library or SDK since a date, with the data sources enumerated (npm, PyPI, crates, Go plus GitHub releases/CHANGELOG). An agent immediately understands the output. It does not, however, distinguish itself from the very similar sibling package-changes, so it falls short of a 5.

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

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

Usage is implied through the data it assembles ('every version published since then... release notes... breaking-looking lines flagged') and the note that it also works for any GitHub repo, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings like package-changes or library-research.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint=false), but the description adds meaningful behavior: pricing per call, that failed calls are not charged, and the free-trial status. These are real operational facts beyond the structured fields.

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

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

Dense but front-loaded, leading with what the tool is, then formats, then limits and price. Slightly redundant in restating pricing across title and body, but every sentence carries information.

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

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

With annotations providing the safety profile and an output schema existing, the description supplies the remaining operational essentials (input formats, token/character limits, charging behavior). Complete enough to call correctly, with only sibling routing 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 description coverage is 100%, so the baseline is 3, but the description adds usable syntax examples ({"prompt": "..."} or OpenAI-style {"messages": [...]}), notes max_tokens up to 1024, and characterizes the ~21,000-character input ceiling, going beyond what the schema alone conveys.

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

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

States a specific verb and resource with the underlying model (Gemma 3 12B) and its positioning as a balanced multilingual model. This implicitly distinguishes it from chat-fast and chat-premium, though it never names those siblings 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?

Describes the use case well ('writing, reasoning and long inputs', 140+ languages) and notes no API key/account is needed, which is clear selection context. However it never explicitly says when to prefer chat-fast or chat-premium instead, so no true 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?

Adds substantial context beyond the annotations: no API key or account needed, ~15,000 character input ceiling, failed calls are not charged, $0.003 USDC per call via x402 or prepaid credits, and current free-trial status. This pricing/billing/auth disclosure is exactly the kind of behavior annotations cannot convey.

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

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

Front-loaded with the model and its purpose, then price and payload formats; every clause carries information. It is dense and slightly run-on with several embedded facts, but nothing is wasted.

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

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

An output schema exists so return values need no explanation; the description covers pricing, auth, input limits, failure billing, and accepted request shapes. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description echoes the schema's own guidance (prompt vs OpenAI-style messages, optional system/max_tokens/temperature/json) and adds only the note that max_tokens tops out at 1024, which the schema already encodes as a maximum.

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 (pay-per-call LLM chat), names the exact model (Llama 3.2 3B), and characterizes its niche (fast, cheap, for classification/extraction/short answers/routing) so it is distinguishable from the sibling chat and chat-premium tools at a glance.

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

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

Gives clear positive context — use this for cheap, fast tasks like classification, extraction, short answers and routing — which implicitly separates it from the premium sibling. It never states when NOT to use it or names chat-premium as the alternative for harder tasks, so the routing condition 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?

The description adds substantial behavioral context beyond annotations: pay-per-call pricing, no API key needed, failed calls not charged, payment methods (x402 or prepaid credits), input size limits, and supported request formats. It complements annotations (readOnlyHint, openWorldHint, idempotentHint) rather than 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 dense but well front-loaded with purpose and model identity, then request format and limits, ending with pricing. It is slightly long and repeats the price from the title, but every sentence carries useful information.

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

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

Given the complexity of a paid LLM chat tool with six optional parameters and a 100% covered schema, the description covers all critical aspects: purpose, request formats, pricing, failure handling, input limits, and what is not included. An output schema exists, so return value details are not needed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds integration-level meaning: it shows a sample JSON body, mentions the 'messages' vs 'prompt' alternatives, and notes max_tokens is up to 1536. It adds useful context beyond the schema field descriptions.

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

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

The description states a specific verb and resource: 'Pay-per-call LLM chat (Llama 3.3 70B)' and names its specialization for harder reasoning, coding, and careful writing. It implicitly distinguishes itself from the sibling 'chat' and 'chat-fast' by calling itself the strongest model and noting it is paid only, but it does not name those alternatives explicitly.

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

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

It clearly indicates when to use this tool: for harder reasoning, coding, and careful writing, and notes that it is paid only (not in the free trial). However, it does not name an alternative for simpler or free tasks or state when not to use it.

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

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

Annotations cover the safety profile (readOnly, openWorld, not idempotent), so the bar is lower; the description adds real context beyond them: the data is 'live', coverage depends on UK Companies House being 'enabled', and it is priced at $0.03 per call via x402/prepaid credits. It does not mention rate limits or freshness/latency, keeping it short of a 5.

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

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

Content is front-loaded: what it returns, then scope, then the alternative tool, then pricing. Dense but each sentence earns its place; the pricing/trial sentences are useful for an agent that must consider cost.

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

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

An output schema exists, so return values need not be described, and the annotations carry the safety profile. For a 2-parameter, read-only enrichment tool the description is nearly complete; only the sibling boundary with company-techstack is left slightly ambiguous.

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 (name, domain) are already documented with formats and purpose. The description adds no additional syntax or constraints beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

Names a specific resource (live company profile from a domain) and enumerates its concrete contents: techstack, domain age/registrar, security headers, LEI register entities, and UK Companies House matches. It explicitly distinguishes itself from /company/report, so an agent can route without opening either schema.

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

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

Gives clear context (companies only, no personal data) and names an alternative ('For an AI-written report with news use /company/report'). It does not, however, clarify the boundary against the closely-named sibling company-techstack even though it says this tool is a superset of 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 declare readOnly/openWorld; the description adds materially useful behavioral context beyond them: the $0.25 USDC price, x402 or prepaid-credit payment paths, and exclusion from the free trial. It does not explain the idempotentHint=false behavior or whether repeated calls are cached.

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?

Content and scope are front-loaded before the pricing sentence, so the agent hits the purpose first. The single main clause is long and comma-heavy but each element (sources, outputs, scope, price) earns its place.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description completes the picture with price, payment mechanics, scope limits, and report contents; only the caching/idempotency behavior remains unmentioned.

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 only two well-documented parameters, so the schema carries parameter meaning. The description adds no syntax or matching guidance for domain/name beyond what the schema already states, making the baseline 3 appropriate.

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

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

States a specific verb (Research) and resource (a company) and enumerates exactly what the report contains: website, tech stack, domain age, registry matches, and 30 days of news with citations. An agent can tell this is a composite company-research bundle without opening the schema, distinguishing it from narrower siblings like company-profile or company-techstack.

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

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

Gives clear context (research a company in one call) plus scope exclusions: companies only, no personal data, and paid-only (not in the free trial). It does not explicitly name alternatives such as company-profile or company-techstack for agents wanting a lighter call, so routing is only partially addressed.

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/openWorldHint, and the description usefully adds behavioral context beyond them: 'Cached daily' (data freshness), the $0.01 USDC cost via x402 or prepaid credits, and the free-trial status. Cost and cache behavior are exactly the kind of details annotations cannot convey.

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

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

Front-loaded with the core capability, followed by two short sentences covering freshness and pricing. Dense but each sentence carries distinct information; the category list is long but informative 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?

An output schema exists, so return values need not be described. Between the category enumeration, the cache cadence, and the pricing model, an agent has everything needed to select and invoke the tool correctly.

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

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

Schema description coverage is 100% and both parameters already document their purpose (name improves matching, domain is the website domain). The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('What technology a company uses, from its website and DNS') and enumerates the detected categories (CMS, frameworks, analytics, payments, hosting/CDN, email, DNS records, social profiles). An agent can distinguish this from siblings like company-profile or dns 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?

Usage is implied by the tool's nature — supply a domain, get its techstack — but there is no explicit when-to-use guidance and no named alternatives or exclusions (e.g., versus company-profile or dns). Adequate but with a clear gap.

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

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

Annotations already declare readOnlyHint/openWorldHint/non-idempotent, so the safety profile is covered. The description goes beyond that by disclosing the analytical behavior (conflicts explained, end-of-life runtimes flagged), the 20-package cap, and the pricing model ($0.005 USDC via x402 or prepaid, free trial) – genuinely useful context for invocation decisions.

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

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

A single dense paragraph that front-loads the core question and capability before tacking pricing onto the end. No wasted sentences, though the clause about engines/peer deps is fairly packed.

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 an output schema present, return values need not be explained. The description covers inputs, limits, ecosystems, pricing and behavior adequately; the only gap is the absence of any routing against the numerous sibling compatibility/audit tools.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add the 20-package limit and the accepted version format ('exact versions, ranges or latest'), but these largely restate the schema's own maxItems and examples, so value beyond structured fields is marginal.

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 leads with a specific question ('Do these package versions work together and on your runtime?') and names the exact mechanism – engines, peer dependencies, Requires-Python/Requires-Dist checked against each other and the runtime. It's concrete about verb and resource, though it doesn't name a sibling (e.g. package-check, dependency-verdict) to distinguish itself.

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 through the input shape ('Give up to 20 npm or PyPI packages... plus your Node or Python version'), which tells the agent what to supply, but there is no explicit when-to-use-this-vs-alternatives guidance despite many overlapping siblings (package-check, package-audit, dependency-report).

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 and openWorld, but the description adds traits they don't cover: robots.txt compliance, the 10-page ceiling, output composition, and the pricing/auth model ($0.03 USDC via x402 or prepaid credits, free trial). That is genuine behavioral context beyond structured fields; it only lacks detail on partial failures or 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?

A single dense paragraph that is front-loaded with the core behavior and ends with price/trial metadata. Every clause carries information, though the pricing sentence is slightly tangential to invocation guidance.

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 an output schema present and rich annotations, the description needn't explain return values, and it covers discovery method, limits, compliance, and cost. Complete enough to call correctly; only sibling routing is thin.

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 url, path, and maxPages are already documented, including the path default and the 1-10 bound. The description only reinforces the page cap and output fields, so baseline 3 is appropriate.

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

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

States a specific verb+resource+scope: turns a small website or one section into clean Markdown, and names the discovery mechanism (sitemap or same-site links) plus the return shape (title, Markdown, address, up to 10 pages). An agent can distinguish this from siblings like sitemap, markdown, or extract 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?

"Great for docs, blogs and company sites" implies when it fits, and "small website, or one section of it" implies the scale boundary. However, it gives no explicit when-not guidance and never names alternatives (e.g., sitemap for page discovery, extract for single-page reads), 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuinely useful behavioral context beyond them: DST-aware time-zone handling, supported format variants (5-field, 6-field, names, macros), and the $0.001 USDC cost with trial status.

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

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

Three tight sentences: capability first, then supported formats, then price/trial. No padding, and the core function is front-loaded before commercial details.

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

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

With an output schema present, return values need not be described, and the description covers formats, time-zone handling, and limits adequately for a read-only explanation tool. Only the absence of usage guidance keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the tz, count, and expression parameters are already well documented with defaults, ranges, and examples. The description's mentions of 'any time zone' and format support only lightly reinforce what the schema already conveys, so the baseline 3 is appropriate.

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

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

States a specific verb pair (validate + explain) and resource (cron expression), then enumerates the exact outputs: plain-English meaning, per-field expansion, and next run times. Clearly separable from other 'explain' siblings like regex-explain or sql-explain.

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 its use case (you have a cron expression and want it explained/validated) but never states when to reach for it versus an alternative or any prerequisite. No explicit when/when-not guidance is present.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint). The description adds genuinely new behavioral context beyond them: the exact enrichment returned (CVSS, EPSS, CISA KEV) and, notably, the per-call pricing model ($0.003 USDC via x402 or prepaid credits, free trial), which is material to invocation decisions.

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

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

Front-loaded with the core purpose and efficiently packaged as two mode clauses plus a pricing sentence. The first sentence is dense and run-on, but every clause carries information; 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 an output schema present, return structure need not be explained, and annotations cover safety. The description still supplies mode semantics, enrichment fields, and pricing, leaving it complete enough for correct invocation; only sibling routing is unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by establishing the disjoint usage contract between 'id' and 'package/version/ecosystem' (mutually exclusive modes) and supplying concrete examples (CVE-2021-44228, lodash, npm) that the schema does not state.

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 ('Vulnerability lookup') and enumerates two concrete modes (by id, by package) with supported ID formats, so the agent knows exactly what it returns. It does not differentiate from adjacent siblings like package-audit, package-check, or dependency-report, 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?

It clarifies the two usage patterns (lookup by id vs. list-by-package with optional version), which is useful implied guidance. But it never says when to prefer this over similarly-scoped siblings (package-audit, dependency-verdict, package-check), so routing guidance remains incomplete.

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, so the safety profile is covered. The description adds behavior beyond that: a live 'TVL suddenly crashing' alert mode (which explains the non-idempotent result set) and the payment/auth model ($0.005 in USDC via x402 or prepaid credits, free trial). These are useful operational facts the annotations do not carry.

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

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

The first sentence is dense and front-loaded with the useful payload. However, the trailing 'Filters: Price: $0.005...' fragment is mislabeled and dangling - it calls pricing a 'filter' while omitting the actual filter parameters, which is mildly confusing structure and waste.

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

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

An output schema exists, so return-value detail is not required, and the description still summarizes the payload plus a live-alert mode. All five params are schema-documented. Coverage is good, though the missing when-to-use guidance is a small gap for a data tool in a crowded sibling set.

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

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

Schema description coverage is 100%, so all five filters (days, chain, limit, protocol, minAmountUsd) are already documented in the schema. The description does not add format, default, or syntax 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?

States a specific verb+resource: it delivers 'recent crypto hacks and exploits (DeFi, bridges, exchanges) from DefiLlama's database' and enumerates the returned fields (date, amount, technique, chains, funds returned, totals, live TVL-crash alerts). This is content-distinct from siblings like defi-protocol and defi-yields, so an agent can tell what it fetches without opening the schema.

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

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

The description never says when to reach for this tool versus alternatives (defi-protocol, token-safety, etc.), nor what prerequisites apply. Usage is only implied by 'recent hacks,' with no exclusions or routing to 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 the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds genuinely useful behavioral context the annotations do not: the per-call cost ($0.01 USDC), the payment mechanisms (x402 or prepaid credits), and free-trial availability. It does not disclose rate limits or latency, which keeps it out of the top band.

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 verb and resource, then the returned data, then pricing. The long enumeration of fields is dense but all of it scopes what the tool actually returns. No filler sentences.

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

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

With an output schema present, the description need not explain return values, and an output schema plus annotations plus a single fully documented parameter means an agent has nearly everything. The only missing element is any guidance on choosing this tool over overlapping siblings such as defi-exploits.

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 schema itself providing the 'Aave V3 or aave-v3' example, so the schema already carries the parameter semantics. The description adds nothing about the name/slug argument, making 3 the correct baseline.

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

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

States a specific verb+resource ('DeFi protocol safety check') and enumerates the exact data returned (TVL with 1h/1d/7d change, chains, category, audits, oracles, age, forks, hacks) plus the shape of the result (flags, 0-100 score, verdict). That is far more than a restatement of the name. It does not, however, explicitly differentiate itself from close siblings like defi-exploits or token-safety.

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, when-not-to-use, or alternative-tool routing. The use case is only implied by the phrase 'safety check', and the neighboring defi-exploits tool (past hacks) overlaps with the hacks data this tool advertises, yet no guidance distinguishes them.

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

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

Annotations cover read-only/open-world/idempotency, and the description adds genuinely useful non-annotation context: cost ($0.01 in USDC per call via x402 or prepaid credits, plus a free trial) and the risk model behind the ranking. It stops short of stating rate limits or result freshness, 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 dense sentences plus a short example: output fields and risk methodology come first, then example, then filters and price. No filler, and the most decision-relevant information (ranking basis, cost) is front-loaded.

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

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

With an output schema present, the description does not need to enumerate return fields, though it does so anyway. It covers cost, ranking logic, filters, and an example — sufficient for a zero-required-parameter query tool, with only minor redundancy against the output schema.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented with enums and defaults. The description only restates the filter list and gives one example tuple, adding little syntax or semantics 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+scope: 'Best DeFi yields for a token and chain, ranked by risk-adjusted APY (sustainable APY, discounted for risk)'. This clearly distinguishes it from siblings like defi-protocol (protocol metadata) and defi-exploits (hack history) by describing a ranked pool-yield lookup.

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

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

It provides a concrete example invocation ('token: USDC, chain: base, minTvlUsd: 1000000') and lists available filters, which implies usage. However, it never says when to prefer this over adjacent tools (defi-protocol, token-report, stablecoin-depeg) or state prerequisites/exclusions, so routing guidance is only implied.

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

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

Annotations already cover the safety profile (readOnly, openWorld), so the description's added value is the commercial/access behaviour: $0.08 USDC per call, x402 or prepaid credits, and exclusion from the free trial. That is genuinely useful gating information an agent cannot get from the schema. It does not disclose latency, caching, or why idempotentHint=false (the AI comparison may vary), which are minor gaps.

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

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

Two sentences: a dense but front-loaded feature list, then a separate pricing/access sentence. Every clause earns its place given the breadth of the report, though the first sentence is long and packs eight distinct outputs into one run-on.

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 an output schema present, return values need not be documented, and the description covers scope, cost model, and access restrictions for a high-complexity paid tool. The only missing piece is explicit routing guidance to sibling tools covering overlapping subsets.

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 enums and defaults fully documented for name, usage, project, version and ecosystem, so the schema carries the parameter burden. The description only gestures at project/usage via 'licence compatibility with YOUR project and usage', adding 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?

Names a specific verb+resource (a dependency decision report) and enumerates the exact content: vulnerabilities, malware, typosquats, deprecation, GitHub repo health, licence compatibility, alternatives, and an AI use/use-with-care/avoid verdict. An agent can tell this is an aggregate report rather than a single check. It stops short of naming siblings such as dependency-verdict, package-audit, license-check or repo-health, so the boundary against those overlapping tools must be inferred.

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 framing question 'should I use this dependency?' strongly implies the use case, and the pricing/access note (paid only, not in the free trial) tells the agent when it is *available*. However there is no comparison against the cheaper siblings (package-check, dependency-verdict, license-check) that cover subsets, so the agent must guess when to spend $0.08 versus a narrower tool.

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

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

Annotations already declare readOnlyHint/openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: the exact price ($0.03 USDC per call, x402 or prepaid credits), the free-trial availability, and the fact that it wraps both a package scan and a GitHub repository health check. It doesn't explain the idempotentHint=false / per-call cost interaction explicitly, 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?

The question-style lead sentence is front-loaded and directly useful, and the price sentence is separated out. The check list reads as a long parenthetical, but each item (vulnerabilities, malware, typosquats, deprecation, licence, downloads, repo health) earns its place by defining scope.

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 an output schema present and 100% schema coverage, the description needn't explain return values and correctly outlines the verdict format. It is complete enough to call correctly; only the sibling-differentiation gap and idempotency/cost nuance keep it from full marks.

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

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

Schema description coverage is 100%, so all three params (name, version, ecosystem) are already documented. The description echoes the supported ecosystems and the default-version behavior but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific question it answers and names the resource (package safety check + GitHub repo health) with a concrete output (use/use-with-care/avoid). It's clear what it does, though it never names or contrasts with the many overlapping siblings like package-audit, package-check, dependency-report, and repo-health, which it effectively combines.

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?

'Should I use this dependency? in one call' implies the adoption-decision context, and 'in one call' hints it bundles work that siblings split. But there is no explicit when-to-use or when-not, and no alternative named among the crowded package-*/repo-* siblings, 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 declare read-only, open-world, non-idempotent. Description adds valuable behavioral context: uses DNS-over-HTTPS (Cloudflare 1.1.1.1), reports DNSSEC validation and NXDOMAIN, and specifies price and payment methods. No contradiction.

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

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

Front-loaded with purpose, then special case, backend details, and cost. Every sentence earns its place; no wasted words.

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

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

Complete for a simple lookup tool with annotations and an output schema. Description covers purpose, usage, behavior, and cost; return values are handled by the output schema.

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

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

Schema coverage is 100%, and the schema already documents both parameters including reverse lookup for PTR. Description largely repeats this (lists record types, mentions PTR) without adding new semantic meaning, so baseline 3 is appropriate.

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

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

States a specific verb ('Look up') and resource ('DNS records'), lists supported record types, and covers reverse lookup. No direct sibling exists, so differentiation is implicit but clear.

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

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

Provides clear context: use this to look up DNS records for any domain, with special handling for PTR. No explicit when-not or alternatives, but none are needed given the unique functionality.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds genuinely useful context beyond that: it queries endoflife.date, explains why staleness matters (missed security patches), returns a verdict plus reasons, and discloses the $0.005 x402/credit pricing and free-trial status. It does not describe pagination or caching behavior, and the non-idempotent hint is left unexplained, but for a low-risk read lookup this is solid added context.

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

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

Front-loaded with the decision question, then a dense but purposeful checklist of evaluated signals, the scope exclusion, and pricing — every clause carries information. The middle catalog of signals runs long as a single sentence, which slightly hurts scannability but not correctness.

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

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

An output schema exists, so return-shape exposition is unnecessary, and the description still conveys the substance of the result (verdict + reasons) and the data sources involved. Annotations cover the safe-read profile. Only minor gaps remain (no mention of latency/caching or error behavior on unknown images).

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

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

Schema description coverage is 100% and the single 'image' parameter is documented with concrete examples (node:20-alpine, nginx, bitnami/redis:7.2), so the schema carries the burden. The description implies the tag/repository split matters (mutable tags like latest, tag OS version) 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 assessment task on a specific resource ('Should you build on this Docker Hub image?') and enumerates the exact signals checked: official status, deprecation, rebuild recency, mutable tags, pulls, architectures, size, EOL runtime/OS. It also names a sibling domain it is not ('Not a CVE scan'), so an agent can separate it from cve and package-audit without opening schemas.

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?

Framed as a pre-build decision question, which gives clear context for when to reach for it, and the 'Not a CVE scan' exclusion actively routes the agent away from this tool for vulnerability questions. It stops short of naming a positive alternative (e.g. cve or package-audit) for those cases, so it is clear context without full alternative 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/openWorld/idempotent=false, and the description adds genuinely useful behavior: answers are source-grounded and cited, it 'Says so when the docs don't cover it' (a refusal contract), and it discloses pricing ($0.02 USDC via x402 or prepaid credits). Cost and payment mechanics go well beyond the annotations.

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

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

Front-loaded with purpose and sources, then constraints, then pricing and the free alternative. Slightly padded by the promotional opener '★ One of our best tools,' but every other clause carries substantive information.

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

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

With a 100%-covered schema, annotations covering safety, and an output schema that carries return shape, the description's job is mostly to add provenance, refusal behavior, and cost — all present. Only minor usage boundaries are 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%, so the library, question, and ecosystem parameters are already fully documented with examples and an enum. The description echoes the ecosystem list but adds no syntax or constraint detail beyond the schema; baseline 3 is appropriate.

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

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

States a specific verb (answer) and resource (coding question about npm/PyPI/crates/Go libraries) with the answer's provenance ('written only from its current docs') and contents (code example, version, cited sources). This clearly distinguishes it from docs-lib and docs-find, which appear as siblings.

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

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

Explicitly routes the agent: 'Try docs-lib free first,' and flags that this tool is 'Paid only (not in the free trial)' so the agent can weigh cost before calling. It stops short of stating when an answer is inappropriate (e.g., pre-release docs or non-library code questions), so it is not fully exhaustive.

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, openWorld, and idempotent=false, yet the description adds genuinely new behavioral context: the returned payload (titles, sizes, page counts, homepage, repository) and the pricing/auth model (USDC per call via x402 or prepaid credits, free trial). That cost and payment-path disclosure is valuable for agent decision-making and is absent from structured fields.

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

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

Front-loads the core capability, then states pricing. The single long sentence is dense but every clause earns its place; the pricing sentence is short and separate. Minor verbosity from enumerating ecosystems twice.

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 an output schema present and annotations covering safety, the description need not explain return values, yet it does so anyway plus adds pricing. It is complete enough for an agent to select and call the tool, with only the absence of sibling routing as a residual gap.

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

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

Schema description coverage is 100%, so parameters are already well documented, establishing a baseline of 3. The description adds only light conceptual framing ('project's docs site' vs. 'company domain') and does not expand on syntax or precedence when both site and library/ecosystem are supplied.

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 the AI-ready docs for any library or API') and details what it scans: docs sites from npm/PyPI/crates/Go metadata, or company domains, for llms.txt and llms-full.txt. Distinguishes itself conceptually from siblings like docs-lib and docs-answer, but never names or contrasts them 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?

The two input paths (project metadata vs. company domain) are implied through the site/library parameters, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings such as docs-lib, docs-answer, or library-research. Usage must be inferred.

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

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

Annotations cover readOnly=true, openWorld=true, idempotent=false. The description adds genuinely useful behavioral detail beyond them: the fallback chain (llms.txt → docs pages → latest release README), section trimming to topic, token-budget enforcement, inclusion of sources and current version, and the pricing/auth model (USDC via x402 or prepaid credits, free trial). This is real added context, not repetition.

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 capability, then behavior, then price. Mostly efficient and information-dense, but '★ One of our best tools' is marketing filler and the price is stated both in the title and the body, a mild redundancy.

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

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

An output schema exists, so return-format explanation is unnecessary, and the description supplies the fallback strategy, filtering behavior, and billing model an agent needs. It only lacks explicit sibling routing, a minor gap for this tool.

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

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

Schema description coverage is 100%, so the four parameters are already well documented; that sets the baseline at 3. The description adds only marginal semantic value, echoing topic-relevance and token budget without new syntax or format guidance.

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: retrieves up-to-date documentation for npm/PyPI/crates/Go libraries, trimmed for LLM context. It clearly says what it does and even how (llms.txt, docs pages, README fallback). It does not, however, explicitly differentiate itself from siblings like docs-answer or docs-find, which an agent must distinguish.

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 via 'Stops agents using stale APIs,' giving a motivating context, but there is no explicit when-to-use vs when-not, and no alternatives named among the many docs/package siblings. The agent must infer the routing itself.

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

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

Adds real behavioral context beyond the annotations: 'Does not contact the mailbox' clarifies this is a passive check rather than a deliverability probe, and the pricing/credit/trial details let the agent reason about cost. Annotations already cover read-only and open-world traits, so this is additive.

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

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

Front-loads the purpose, then delivers the check list and the two constraints (no mailbox contact, pricing) in compact clauses. No filler sentences and nothing repeated from 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?

An output schema exists so return values need not be explained, and the description still covers scope, safety caveat, and commercial terms. Nothing an agent needs in order to call this one-parameter tool correctly is missing.

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

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

There is a single parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds no format, length, or normalization guidance for the email input beyond what the schema states.

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 ('Check an email address') and then enumerates exactly what facets are checked (syntax, MX with fallbacks, disposables, role accounts, free providers, typo suggestions). This is far more discriminating than any sibling tool name suggests.

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 opening clause 'before you use it' gives clear intended timing/context for invoking the tool, which is genuinely actionable. It stops short of naming when NOT to use it or pointing at alternatives, but no sibling competes directly for this job.

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?

Despite annotations covering read-only, open-world, and non-idempotent traits, the description adds substantial behavioral context beyond them: the specific model and dimensions, input limits (32 texts of 8,000 characters), pricing model ($0.002 USDC per call via x402/prepaid), no API key needed, and free trial availability.

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 purpose and key facts, and most sentences earn their place. There is slight redundancy in pricing (title and description both state $0.002, and 'One price per call' precedes the price line), but overall it remains tight 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 the output schema exists, the description need not explain return values. It sufficiently covers model, dimensions, input format, limits, pricing, and auth requirements, so an agent has everything needed to call the tool correctly.

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

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

With 100% schema description coverage, the schema already documents both parameters. The description adds useful request-format examples and clarifies the mutual exclusivity of `input` and `text`, plus the per-text character limit and array size, which go beyond the schema's raw types and limits.

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 (embeddings) and resource (1024-dimension multilingual vectors via BGE-M3, 100+ languages), and names use cases (semantic search, clustering, RAG). It is immediately distinguishable from sibling tools like chat, summarise, and search.

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

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

The description clearly indicates when to use the tool: for semantic search, clustering, and RAG. It does not name alternatives or exclusions, so it is clear context without 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 cover read-only and open-world traits, but the description adds substantial context beyond them: pricing ($0.03 USDC via x402 or prepaid credits), free-trial availability, that paths/line numbers are stripped, that accepted answers are read in full, and that it honestly reports when nothing matches. It does not contradict any annotation.

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 workflow is front-loaded in the first sentence and the operational notes follow. Slight redundancy: the $0.03 price appears in the title and again in the description body, costing a little 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?

An output schema exists, so return values need not be enumerated, yet the description still characterizes the output (likely cause, concrete fix steps, cited sources, plain no-match statement). Combined with input guidance and pricing, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the schema already documents library, message (including the stripping behavior), and the ecosystem enum. The description only restates 'optionally the library' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (explain and fix an error) plus the mechanism: finds matching GitHub issues and Stack Overflow questions, reads accepted answers, and writes cause + fix steps with citations. It also differentiates from the sibling error-known by describing the relationship ('like /error/known').

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

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

Gives clear invocation context ('Paste the error (stack traces fine) and optionally the library') and implicitly routes the known-error lookup case to /error/known. It does not explicitly state when NOT to use it or contrast it head-to-head with siblings beyond the parenthetical reference.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely useful behavior beyond them: inputs are cleaned of paths and line numbers, three search sources are queried, and results carry status, links and excerpts. It also discloses pricing ($0.005 USDC per call, x402 or prepaid, free trial), which no structured field conveys. It doesn't explain result ranking or result-count limits, keeping it short of a 5.

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

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

Front-loaded with the key question and the search scope, then the alternative, then pricing. The middle sentence is dense but every clause carries information; only the pricing mention slightly competes with the functional framing.

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 an output schema present, the description needn't detail return values, and it nonetheless sketches them (matches, status, links, excerpts). Combined with 100% schema coverage and annotations covering safety, an agent has enough to call it correctly; only edge-case behavior (empty results, rate/cost interaction with the free trial) 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 description coverage is 100%, so the schema already documents library, message and ecosystem (including the enum and defaults). The description reiterates that library is optional and that paths/line numbers are stripped, but adds no syntax or format detail beyond what the schema provides. Baseline 3 is correct.

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

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

The description states a concrete verb+resource (search pasted error messages across the library's GitHub issues, all GitHub issues, and Stack Overflow) and explicitly distinguishes itself from the sibling error-explain tool. An agent can tell immediately this answers 'is this error known?' rather than 'how do I fix 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?

It explicitly routes the agent to /error/explain when a likely fix is wanted, which is clear alternative-handling for the nearest sibling. It doesn't state exclusions (e.g. what happens for very short or non-error inputs) beyond the schema's minLength, but the core when-to-use is unambiguous.

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

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

Annotations already cover readOnly/openWorld/idempotent, so the bar is lower, and the description adds real context: the payment model ($0.002 USDC via x402 or prepaid credits, free trial) and the date fallback behavior ('the last rate published on or before it'). It does not contradict the idempotentHint=false annotation. Minor gap: no statement of rate freshness/update cadence.

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 resource and source, then coverage, date semantics, and pricing in four tight sentences. The pricing sentence is justifiable for a paid tool, though the '$0.002' detail is repeated in 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 an output schema present and annotations covering the safety profile, the description only needs to add what structured fields don't: source, coverage, date fallback, and payment requirements, all of which it supplies.

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 baseline is 3, and the description earns above it by explaining semantics the schema lacks: base conversion ('any base'), the date fallback ('last rate published on or before it'), and that amount conversion is optional.

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 with its authoritative source: 'Official ECB euro foreign-exchange reference rates'. It quantifies coverage (~30 currencies), describes the transformation (converted to any base), and implies historical depth (since 1999), distinguishing it from market/token price 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?

Usage is implied by the data source (ECB official rates) and the 'Latest or any past date since 1999' clause, but there is no explicit when-to-use guidance or routing against siblings like token-price or markets-odds. An agent must infer that this is the official-rate option.

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

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

Annotations already cover read-only and open-world nature, but the description adds genuinely useful behavioral context beyond them: the cost ($0.005 USDC per call via x402 or prepaid credits), the free-trial eligibility, the 'companies only' scope limitation, and what the LEI mode returns (direct and ultimate parents). Does not explain the non-idempotent 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?

Front-loaded with the core purpose and lookup modes, then a short pricing sentence. Dense but nearly every clause earns its place; minor redundancy between the register name and lookup modes.

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 an output schema present, return values need not be explained. The description covers scope, modes, pricing and trial status, leaving an agent able to call it correctly; the only omission is guidance relative to sibling lookups.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the LEI-parent behavior and the national-number usage but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb (look up) and resource (legal entities in the global LEI/GLEIF register), and enumerates the three distinct lookup modes (by LEI, by name, by national company number). This is clearly distinguishable from siblings like company-profile, company-report, eu-vat and eu-fx.

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 by mapping each input to a search mode, but never states when to prefer this tool over related siblings (e.g. company-profile, company-report) or any when-not conditions. Usage is inferable but not explicitly guided.

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

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

Beyond the annotations (readOnly, openWorld, non-idempotent), the description discloses genuinely useful behavior: the check is live against VIES, coverage varies by member state ('where the member state shares them'), sole traders' names are withheld for privacy, and the cost is $0.005 per call via x402 or credits. It doesn't state latency, rate limits, or failure modes for an unreachable VIES.

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

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

Front-loaded with the core action and result, then coverage caveats, then pricing. The pricing sentence is housekeeping rather than capability, but it is short and the whole description is dense without filler.

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

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

For a one-parameter, read-only external lookup whose annotations already carry the safety profile and which has an output schema, the description covers everything needed: what it validates, input format expectations, source system, coverage limits, and cost. Nothing material 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% and the single parameter already includes the country-prefix example (DE811569869), so the description's 'with its country prefix' adds little. The mention that XI (Northern Ireland) numbers are accepted is a mild clarification of accepted input space, keeping this at baseline.

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

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

States a specific verb and resource ('Check an EU VAT number live against ... VIES') and names the exact return values (validity, registered company name, address). It is clearly distinguishable from siblings like eu-fx and eu-lei, which cover different EU data domains.

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

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

Gives clear context for when the tool applies — live VAT verification, including Northern Ireland (XI) numbers — which tells an agent what inputs qualify. It stops short of naming alternatives or stating exclusions (e.g. when a cached/offline check would be preferable, or what to do for non-EU numbers).

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, and non-idempotent, but the description adds substantial behavioral detail: clutter removal, blocking of private/internal addresses, size (2 MB) and timeout (10 s) limits, no charge on rejection, and pricing model. This goes well beyond structured annotations.

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

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

The description is front-loaded with core function and key constraints, and mostly earns its place. Some phrases ('Built for AI agents that need to read the web', 'In the free trial') are slightly promotional, but overall efficient.

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

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

Given the simple input (one required URL), existing output schema, and annotations, the description provides all necessary context: what it returns, key limitations, cost, and safety boundaries. No critical information is missing for correct invocation.

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

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

Schema description coverage is 100%, so the single parameter is fully documented in the schema. The description adds only a brief example ('Pass the page address as url: https://...'), which is helpful but minimal beyond the schema's existing explanation.

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

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

States a specific verb (fetch) and resource (public web page) along with the exact output format (clean Markdown, page title, all links as JSON). It implicitly distinguishes itself from sibling extract-json by emphasizing Markdown+links rather than structured JSON extraction.

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

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

The description gives a general context ('Built for AI agents that need to read the web') but does not explicitly say when to use this tool versus alternatives like extract-json, crawl, or search. No when-not guidance beyond blocked private/internal addresses.

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/non-idempotent, and the description adds substantial non-obvious behavior: the backing model (Llama 3.3 70B in JSON mode), the 40,000-character source cap, that failures are not charged, the $0.03 USDC price via x402 or prepaid credits, and that it is excluded from the free trial. That is meaningful operational context beyond the annotations.

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

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

Front-loaded with the core action and inputs, then use cases, then billing constraints — efficient and scannable. Minor redundancy in repeating the $0.03 price already present in the title, 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 an output schema present, return format need not be explained, and the description covers everything else an agent needs: accepted inputs, size limit, model, pricing, payment paths, failure billing, and trial exclusion. Complete for a paid extraction endpoint.

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% (baseline 3), and the description adds real meaning by expanding what 'url' accepts (web page, PDF, Word, Excel) and restating the 40,000-character source limit. It does not explain the 'instructions' parameter's role beyond what the schema already documents.

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

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

States a specific verb and resource ('AI structured extraction' producing 'JSON that fits' a caller-supplied schema), which is far more precise than the generic sibling 'extract'. The mechanism (source in, schema-shaped JSON out) makes the tool's identity unambiguous even without naming a sibling.

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

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

Gives clear positive context via concrete use cases ('prices, contacts, specs, events, invoices and tables') and the input mode ('give a URL ... or text'), which tells the agent when this fits. It stops short of explicit when-not guidance or naming an alternative sibling (e.g. extract, metadata), so no exclusion criteria are 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 already cover the safety profile (readOnly, openWorld, non-idempotent), and the description adds meaningful context beyond them: pricing/auth (x402 or prepaid credits, $0.003/call, free trial), the discovery behavior via page links or common paths, and ordering (newest first). It does not say what happens when no feed is found or whether results are cached, which keeps it below a 5.

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

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

Front-loaded with the core behavior and output shape, then disambiguates the input, then adds usage and price. Dense but each clause carries information; the price sentence is justified for a paid x402 call.

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

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

An output schema exists, so return values need not be re-explained, and annotations carry the safety profile. Pricing, discovery behavior, ordering and input flexibility are covered; error/empty-result handling and pagination are the only notable omissions.

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

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

Schema description coverage is 100% for both parameters, so the schema already explains that `url` may be a feed URL or any page and that `limit` caps items. The description restates the URL flexibility and adds no format or syntax detail beyond it, matching the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('return titles, links, dates, authors and summaries' for 'latest posts from any site or feed') and names the discovery fallback that makes it unique. It does not explicitly distinguish itself from the sibling 'news' tool, so an agent must infer the difference (arbitrary/site feed vs. aggregated news) rather than being told.

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

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

Gives clear usage context: 'For monitoring blogs, changelogs and news.' That tells the agent when this tool fits. There are no exclusions or named alternatives, so it stops short of the explicit when-not guidance a 5 would require.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds substantive non-schema context: what each result contains (capabilities, exact usage, price, reliability, fit rationale), a neutrality/resale disclaimer, the $0.002 USDC per-call cost via x402 or prepaid credits, and free-trial availability.

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

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

Front-loaded with the core action, followed by input format, output contents, and pricing. A few clauses are promotional ('Neutral: we never resell them') but none are harmful; overall tight for the amount of information conveyed.

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

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

For a read-only discovery tool with 100% schema coverage and an output schema, the description supplies everything an agent needs: input style, result composition, cost, and neutrality. Only the sibling-routing question is left unanswered.

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 job, kind, limit, and maxPrice; the description only loosely echoes the kind split ('x402 APIs and MCP servers side by side') and price. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Find the best tool for a job') and explains the mechanism: natural-language task in, ranked list of pay-per-call x402 APIs and MCP servers out. It does not differentiate itself from close siblings such as x402-find, x402-recommend, or ai-models-pick, 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 implied by the examples ('check if a token is a rug pull', 'cheap LLM chat') and the plain-English framing, but it never states when to prefer this over x402-find/x402-recommend/ai-models-pick, nor any exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read/no-side-effect profile is covered. The description adds non-obvious behavioral context: the $0.002 per-call USDC cost, x402/prepaid payment mechanics, and free-trial availability, which is genuinely useful for an agent deciding to call 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?

One dense but well-structured sentence that front-loads the resource and coverage before any cost details. Slightly overloaded but every clause is informative.

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 an output schema present, return values need not be explained, and the read-only annotation covers safety. The description covers chains, outputs, and pricing; only the absence of usage routing keeps it short of 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 100% and the single 'chains' parameter enumerates all valid values with a statement of the default. The description restates the chain list and default but adds nothing beyond the schema, so baseline 3 applies.

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

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

States a specific resource (live network fees) and enumerates the exact chains and outputs: slow/standard/fast rates, congestion, trend, USD send/transfer/swap costs, cheapest chain. This is easily distinguished from fee-adjacent siblings like token-price or pool-depth.

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 its use case (gas/fee lookups across chains) but never states when to prefer it over alternatives or any exclusions. Usage is inferable but not guided.

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=false, openWorldHint=false and idempotentHint=false, but the description adds genuinely useful context beyond them: the return contents (API key, exact USDC amount and address), the ~15 minute arrival delay, and the post-transfer server URL carrying the key. It does not state whether repeated calls create duplicate keys/charges, which idempotentHint=false hints at.

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 dense sentences, front-loaded with the purpose followed by return contents and payment mechanics. Slight redundancy between the title '(free)' and the closing 'Free to call', but overall efficient with no wasted sentences.

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

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

There is no output schema, so the description carries the return-value burden and does so fully: API key, exact USDC amount and address, network options, delay, and the new server URL. For a two-optional-parameter tool, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the schema already documents network and amountUsd. The description still adds meaning by naming the two supported networks (Base or Solana) and framing the amount as USDC to send, tying the numeric parameter to a concrete currency and transfer action.

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

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

Specific verb+resource: it explains that the tool acquires prepaid credits for continued use beyond the free trial, and it clarifies the actual mechanics (returns an API key plus USDC payment instructions). This distinguishes it from siblings like balance and the x402-* family, which serve different payment/credit roles.

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?

States clear context for use: 'to keep using every tool after the free trial (20 free calls a day).' That tells the agent when this tool is relevant. It does not explicitly name an alternative or a when-not-to-use condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true/openWorldHint=true, and the description adds real value: the specific detection categories, and notably the pricing/cost model (x402 or prepaid credits, free trial), which is not expressible in annotations. It still omits latency/rate-limit behavior, keeping it below a 5.

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

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

Front-loaded with the core question, then a dense enumeration of checks, then the verdict/price tail. Nearly every sentence carries information; the price sentence is arguably appended rather than integral, but it is useful for cost-aware agents.

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

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

An output schema exists, so return values need not be described, and the description still summarizes the shape ('Verdict, score and fixes'). Combined with the check list, an agent has everything needed to call and interpret it correctly; only invocation cost/preconditions beyond price remain 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 there is only one parameter, so the baseline is already satisfied; the description goes further by clarifying the accepted input form ('what follows uses:') and giving a real example (tj-actions/changed-files@v45) that matches the schema's syntax.

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 check (is this GitHub Action safe) on a specific resource (the 'uses:' reference) and enumerates exactly what is examined: OSV advisories, SHA/tag/branch pinning, deprecated Node runtimes, unpinned Docker, nested actions, publisher/repo health. This clearly separates it from siblings like docker-image, package-check, and repo-health.

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?

Tells the agent precisely how to invoke it ('Pass what follows uses:') with a concrete example, and the framing question implies the use case. It does not explicitly name alternative tools (e.g. docker-image for container pins) or state when not to use it, so it stops short of full routing guidance.

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

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

Beyond the annotations (readOnly/openWorld/idempotent=false), the description discloses a critical behavioral trait: cost ($0.10 USDC per call via x402 or prepaid credits) and that it is paid-only and excluded from the free trial. It also reveals the sources consulted and the report structure. It does not mention rate limits or latency, but the pricing disclosure is high-value.

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

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

Front-loads the identity ('Premium research report...') before the mechanics, and the pricing caveat is a short, separate sentence. The middle sentence is dense but earns its place by listing sources and outputs; no obvious padding.

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

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

With an output schema present, return format need not be described, and annotations cover the safety profile; the description fills the remaining gaps (cost model, what is gathered, what the brief contains). Nothing essential to correct invocation is missing, though no guidance on failure/paid-gating behavior is given.

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 goal, library, and the ecosystem enum with defaults. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource ('Premium research report on a library or API for coding agents') and enumerates the deliverable (summary, code, gotchas, risks, plus data sources checked). This clearly differentiates it from narrow siblings like docs-lib, package-audit, or repo-health, though it never names those siblings 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?

The intended context ('for coding agents', 'for your goal') is implied but there is no explicit when-to-use statement versus the many overlapping siblings (docs-lib, package-audit, dependency-report). The scope of its aggregation is described but not the condition that selects it over cheaper 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?

Goes well beyond the annotations (readOnlyHint/openWorld/idempotent) by disclosing cost ($0.003 USDC per call via x402 or prepaid credits), the free-trial availability, an input cap of 50 dependencies, and a 'not legal advice' disclaimer. This is exactly the extra context an agent needs before committing to a paid call.

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

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

A single dense paragraph that front-loads the core purpose, inputs and outputs before pricing. It is slightly overloaded with parenthetical licence examples and payment details, but nearly every clause carries information an agent needs.

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?

Covers inputs, verdict vocabulary, dependency limit, pricing model and legal disclaimer, and an output schema exists for return-value detail. Only minor gap is that it doesn't hint at the shape of the per-dependency reason field beyond naming licence families.

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 each parameter (usage enum, project, dependencies) already carries a full description, so the schema does the heavy lifting. The description restates the same project/usage/SPDX-id examples rather than adding new semantics, 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+resource ('Licence compatibility check') plus the exact inputs accepted (project licence, usage mode, up to 50 dependencies) and the exact outputs produced (ok/conditions/review/incompatible with reason). It is clearly distinguishable from siblings like compat-check, package-audit or dependency-verdict.

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

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

Gives a clear context: describe your project's licence and distribution mode plus dependencies, and receive a per-dependency compatibility verdict. However it never names an alternative or states when NOT to use it (e.g. vs compat-check or package-audit), leaving that 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?

Adds substantial behavior beyond the annotations: 10 MB size cap, private-address blocking, that failures are not charged, and that the response contains title, Markdown, links and character count. Annotations cover safety (readOnly/openWorld), and the description covers billing and failure semantics they do not.

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 transformation and format list, then limits, return fields, the alternative tool, and pricing. Every clause is informative, though the $0.005 price and trial status partially duplicate the title ('Markdown ($0.005)').

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?

Covers input types, size/scope limits, return contents, billing behavior and the sibling alternative. Since an output schema exists, return values need not be enumerated, yet the description does so anyway, leaving nothing essential missing for a one-parameter conversion 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 and schema description coverage is 100%, so the schema already documents 'url' fully; baseline is 3. The description says 'any document URL' and lists accepted formats, which adds minor meaning but no syntax or format specifics 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 ('turn any document URL into clean Markdown') and enumerates the exact input formats supported (web pages, PDFs, DOCX, XLSX/XLS, OpenDocument, CSV, XML, plain text). It also distinguishes itself from the sibling markdown-rendered by scoping JS-heavy sites elsewhere.

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

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

Gives an explicit routing condition and alternative: 'For JavaScript-heavy sites use /markdown/rendered.' It also states a hard constraint (private addresses are blocked) and a 10 MB limit, so the agent knows when this tool applies and when it does not.

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

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

Annotations already cover read-only and open-world behavior, but the description adds valuable operational context: it runs a real headless browser, blocks private addresses, does not charge for failures, costs $0.02 in USDC via x402 or prepaid credits, and is available in the free trial. This is well beyond what the structured fields provide.

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

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

The description is front-loaded with the core purpose and efficiently packs in return values, alternative tool routing, restrictions, and pricing. The only minor redundancy is that the $0.02 price appears in both the title and the description.

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

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

For a one-parameter tool with an output schema and rich annotations, the description covers what the tool does, when to use it versus the cheaper alternative, restrictions, billing behavior, and availability. Nothing important for correct invocation is missing.

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

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

Schema description coverage is 100% for the single url parameter, and the schema already says it must be a public web page address. The description reinforces that private addresses are blocked, but adds little parameter-level meaning 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: reads JavaScript-heavy web pages and returns clean Markdown. It explicitly distinguishes itself from the sibling /markdown tool for ordinary pages and PDFs, so an agent can choose without opening both schemas.

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 says to use /markdown for ordinary pages and PDFs (cheaper), framing this tool's niche as JavaScript-heavy pages such as SPAs, React/Vue sites, and dashboards. It also notes that private addresses are blocked, giving clear boundaries for when the call will succeed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: source (Polymarket), returned fields, pricing ($0.005 USDC per call via x402 or prepaid credits), and free-trial availability.

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 purpose and operating modes, then covers return contents, audience, and price compactly. Every sentence contributes something useful, and there is no redundant explanation.

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 an output schema present, the description need not explain return values, but it still gives a useful preview of returned fields. Combined with complete parameter descriptions and annotations, it is fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description repeats the q search examples and the omit-q behavior, but adds little semantic detail beyond what the schema provides. The baseline 3 is appropriate when the schema carries the parameter documentation.

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

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

The description states a specific resource and source: prediction-market odds from Polymarket. It immediately clarifies the two operating modes (search a topic via q, or omit q for trending markets) and identifies the data returned. This is enough for an agent to distinguish it from generic search, news, or token-price 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?

It gives clear context for use: search any topic or omit q for the most-traded markets now, and it names research, forecasting, and trading agents. However, it does not explicitly compare itself to a sibling alternative or state when another tool should be used instead.

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