ISHOB Knowledge Archive

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 non-obvious operational context the annotations cannot carry: it is paid ($0.05 via x402) and it draws on SEC EDGAR and Wikidata. It still omits failure modes for an unregistered ticker and any rate-limit or latency expectations.

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 value proposition, then the payload breakdown, then sources and price — a sensible order with no filler sentences. The single mega-sentence of enumerated fields is dense, but every clause maps to a real output category rather than padding.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly, listing all four data families plus concrete contents (margins, EPS, 8-K events, 90-day insider activity, TLS expiry, email security). Both parameters are documented in the schema, payment terms are disclosed, and the open-world/read-only behavior is covered by annotations, leaving nothing an agent needs missing.

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

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

Schema description coverage is 100%, so both parameters are already documented, and the descriptions there (ticker example, domain override 'instead of the one on record') are more informative than anything in the tool description. The description adds no parameter-level detail beyond confirming the SEC-registered constraint.

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

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

The description opens with a specific verb/resource and scope ('Company snapshot in one call for any SEC-registered company') and then enumerates the exact payload categories: fundamentals, SEC profile, recent filings, and website health. An agent immediately knows what it returns. It never names the overlapping siblings (finance_snapshot, domain_intel, site_audit), so an agent must infer differentiation from the breadth of the enumeration 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?

Usage is only implied: 'in one call' suggests it aggregates what several narrower tools return, and 'for any SEC-registered company' bounds the input. There is no explicit when-to-use versus finance_snapshot/domain_intel, no exclusions, and no stated prerequisites for obtaining the paid credential.

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 annotations (readOnlyHint, openWorldHint) by disclosing the pricing model ($0.001, x402) and the failure behavior for unverified contracts (404, not charged). It also names the data source (Sourcify) and proxy-resolution behavior, adding real operational 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?

A dense, front-loaded lead sentence covers the resource and return contents, followed by two short sentences for the error and pricing behavior. Minimal waste, though the lead sentence is long.

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

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

With no output schema, the description carries the return-value burden well, enumerating compiler/deployment/signatures/proxy output and the source-size bound. Pricing and error handling are covered, so little is left for the agent to guess.

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 meaning: 'proxy resolution to the implementation ABI' clarifies resolve_proxy and 'optional Solidity/Vyper source' clarifies include_source, giving purpose beyond the terse schema 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?

States a specific verb+resource ('Verified smart-contract ABI ... from the Sourcify registry') and enumerates exactly what is returned (compiler, deployment, function/event signatures, proxy resolution). This is clearly distinguishable from siblings like token_audit or explain_transaction.

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 context (verified contracts on supported EVM chains, sourced from Sourcify) but never explicitly states when to use this versus alternatives such as token_audit or simulate_tx. 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 cover readOnlyHint and openWorldHint, so the safety profile is handled. The description adds genuinely new behavioral context: the $0.001 x402 payment requirement and the fact that figures are derived solely from public chain state rather than any external price feed. It stops short of describing latency or rate limits, 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?

The single dense paragraph is front-loaded with the core capability and ends with the payment terms, and every clause adds concrete information (chains, pool depth, confidence). It is slightly long, but no sentence is 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?

A read-only tool with no output schema, so the description reasonably covers what comes back (pool depth, confidence, 24h change, APY, market size) and the cost model. It leaves some gaps around response shape and error behavior, but is largely sufficient 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 coverage is 100%, so the schema already documents tokens, change_24h, and yields_chain with examples and enum. The description only adds marginal interpretation, e.g. clarifying the yields screener returns supply/borrow APY and market size, which is the baseline 3 given 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 (computes live token prices) and resource (on-chain DEX pools across named chains), plus a secondary Aave V3 yield screener. The data-source detail and chain list make it clearly distinguishable from siblings like token_report, token_verdict, or wallet_portfolio.

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 conveys context (derived from public chain state, no third-party feed) and a paid x402 cost, which implies when it's appropriate versus free feeds. However, it never explicitly names an alternative tool or states when-not-to-use, so usage selection is left to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds two traits they do not cover: this is a paid call ($0.0004 via x402) and results are returned 'with evidence'. Pricing/payment model is exactly the kind of behavioral context annotations cannot express. It omits any error or rate-limit behavior, 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?

One dense sentence covering the three data categories plus a short second sentence for the pricing. Front-loaded and essentially waste-free, though the parenthetical enumerations make it read as a run-on that takes effort to parse.

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

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

With no output schema, the description carries the burden of describing returns, and it does so well by listing the specific fields each check produces. For a single-domain lookup the missing pieces (error cases, timing) are minor.

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 both parameters and the baseline is 3. The description adds real meaning by spelling out what each 'checks' value yields — registration data, DNS records, and tech stack — which the enum alone does not convey.

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

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

The description names a specific resource (a domain) and enumerates exactly what intel it produces across three dimensions (RDAP registration, DNS records, homepage tech stack). It is far more concrete than the sibling names alone, but it never explicitly positions itself against lookalikes such as site_audit, site_metadata, or resolve_name.

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

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

There is no when-to-use or when-not guidance and no mention of alternatives. The only hint of scope is the parenthetical 'unregistered = likely available', which implies a use case but does not tell the agent when to pick this over a sibling.

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

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

Annotations only cover readOnlyHint and openWorldHint, so the description carries the rest and does well: it discloses batch cap (100 strings), per-call character limit (24,000), model dimensions/languages, normalization, and a paid cost model via x402. The only gap is that the exact return structure is not described.

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

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

Two dense sentences with no filler; the core purpose and the model/pricing specifics are front-loaded. Every clause (batch cap, char cap, cost) carries information, though the model enumeration makes it a touch crowded.

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

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

For a two-parameter tool with full schema coverage and no output schema, the description is nearly complete: it covers purpose, models, limits, and cost. It stops short of describing the response shape (e.g., an array of vectors per input), the one piece an agent must infer.

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 3 is the baseline, but the description adds real value by declaring bge-small-en-v1.5 the default and clarifying the input accepts a single string or a list. The default-value information is not present in the schema.

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

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

States a specific verb (produce embeddings) and resource (text), names the output artifact (L2-normalised vectors), and enumerates the two supported models with dimensions and languages. An agent immediately understands it is the embedding tool, and no sibling overlaps this space.

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?

Frames the intended use as 'RAG / semantic search' and gives concrete capacity guidance (one string or up to 100 strings), but offers no explicit when-to-use/when-not conditions or alternatives. Since no sibling tool competes for this task, the lack of exclusions is understandable.

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, and the description does not contradict them. It adds genuinely non-schema context: the output is rule-based with no AI, the cost ($0.005, x402 paid), and the six supported chains. This is useful behavioral disclosure beyond the structured fields, though it omits latency or failure-handling 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?

Front-loaded with the core purpose, then dense enumerated detail that all earns its place given the richness of the return. Slightly sprawling as a single run-on sentence, but no filler.

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

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

With no output schema, the description carries the burden of explaining return values and does so exhaustively (action classification, USD net changes, approve events, decoded calls, fees). Safety is covered by annotations and payment/coverage are disclosed, leaving nothing an agent needs to invoke 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?

Both parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description restates the supported chains, which loosely maps to the chain enum but adds only display-name context ('BNB Chain' vs 'bsc') beyond what the schema already provides.

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 (explain) and resource (mined transaction) and enumerates exactly what the explanation covers: swap/transfer/approval/NFT actions, net token deltas, movements, approvals, decoded function, and fee. The 'mined' qualifier implicitly separates it from the sibling simulate_tx, which acts on unexecuted transactions.

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 'any mined transaction' but there is no explicit when-to-use, when-not, or named alternative (e.g., simulate_tx for previewing, token_flows for raw movement data). An agent must infer the boundary from the phrase 'mined'.

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

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

With no annotations provided, the description carries the full behavioral burden and discloses unusually rich traits: compliance (robots.txt respected), data retention (nothing stored), capability boundary (no OCR), cost/payment mechanism ($0.001, x402), and size/page limits. This gives the agent a strong operational picture.

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 a single, dense, front-loaded sentence plus terse fragments. Every element earns its place: output format, source types, limits, compliance, cost. No filler or repetition.

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

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

Given the tool's complexity (PDF/HTML parsing, cost, compliance), the description covers all critical dimensions: what it returns, what it accepts, key limits, and payment. No output schema is mentioned, yet the return shape is described. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100% – both the 'url' and 'pages' parameters are documented in the schema. The description mentions the page limit and source type but adds no syntax or format details beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb ('extract') and resource ('tables') and adds the return format ('structured JSON (rows, header, records keyed by column)') plus supported source types. Sibling tools are unrelated, so no differentiation is needed. An agent immediately knows exactly what this tool produces and from what.

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 usage context: public PDF or HTML pages, multi-column/ruled tables, up to 30 pages and 10 MB, with colspan/rowspan expansion for HTML. It implicitly excludes scanned documents by stating 'No OCR', but does not explicitly name when-not-to-use scenarios or alternatives, keeping it just below a perfect score.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses several non-obvious operational facts: the fetch is live, robots.txt is honored, content is not stored or redistributed, and the call is paid ($0.001 via x402). That is meaningful context for a read-only tool. It stops short of a 5 because failure behavior and how the x402 payment is actually authorized are left implicit.

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

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

Three compact sentences, front-loaded with the core action and output, followed by compliance/data-handling and cost. Every sentence carries distinct, decision-relevant information with no filler.

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

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

With no output schema, the description usefully states the return format (clean Markdown) and adds cost and data-handling facts, which is enough for an agent to call it correctly. It omits edge-case behavior (JS-rendered pages, fetch failures), keeping it from a 5.

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

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

There is a single parameter with 100% schema description coverage ("Public http(s) URL"), so the schema already carries the parameter semantics. The description's mention of "public web page" only loosely reinforces the constraint and adds no format or syntax detail, 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?

The description pairs a specific verb (fetch/extract) with a specific resource (public web page) and states the output form (clean Markdown), so the agent knows exactly what it gets. It does not differentiate itself from close siblings such as extract_tables, screenshot, or render_document, 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?

"Public web page" and "robots.txt respected" imply the usage context (open, crawlable pages), but there is no explicit when-to-use guidance and no naming of alternatives like screenshot or extract_tables. Usage is inferred rather than stated.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses real behavioral facts: it is a paid call ($0.001, x402), the data is public-domain annual-filing data, and P/E and market cap are deliberately null while EPS and shares are supplied. Disclosing a payment mechanism and output limitations is genuine added context, though it says nothing about rate limits or response shape.

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: the core purpose leads, followed by the field inventory and the null-field caveat. The semicolon-separated field list is long yet each clause earns its place; only minor trimming is possible.

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

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

With no output schema, the description carries the burden of describing return values and does so field-by-field, plus warns which metrics are null. For a one-parameter read tool this is nearly complete; the missing piece is how it relates to its closest sibling.

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 ticker parameter is fully documented there with format examples (AAPL, MSFT, BRK-B). The description adds only the mild constraint that the company must be US-listed/SEC-registered, 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 ('Fundamentals and ratios for a US-listed company from its latest annual SEC filing') and enumerates the exact fields returned, so an agent knows precisely what it gets. It does not, however, distinguish itself from the obvious sibling company_snapshot, leaving the agent to infer which snapshot to pick.

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 source scoping ('latest annual SEC filing', 'US-listed') and the null-field caveat hints that price data must come elsewhere, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., company_snapshot or crypto_prices).

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 read-only and open-world profile, but the description adds genuinely useful behavioral context: the data window (last 20 blocks) and, notably, the paid cost model ($0.0001 via x402), which signals a payment requirement an agent would not otherwise anticipate. Return format and rate limits remain unspecified.

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?

Purpose is front-loaded in the opening clause, and the dense semicolon lists map directly to returned fields, so most tokens earn their place. It is on the long side, but the enumeration is informative rather than padding.

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

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

With no output schema, the description carries the burden of describing returns, and it does so thoroughly (fee tiers, cost estimates, congestion, block metrics, Solana specifics). The only meaningful gap is the absence of when-to-use guidance relative to sibling 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 description coverage is 100%, so both parameters (usd, chains) are already documented, including the full chain enum list. The description restates the chain set but adds no syntax or default nuance 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?

The description names a specific verb+resource (real-time gas fees and network health) and enumerates the exact chains and metrics covered, down to EIP-1559 tiers and Solana priority-fee percentiles. An agent can immediately distinguish this from siblings like crypto_prices, swap_route, or simulate_tx.

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 is rich on what the tool returns but silent on when to choose it over siblings. There is no explicit 'use this when' guidance or exclusions (e.g., against crypto_prices for token prices), so selection is left to inference from the metric list.

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

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

Annotations declare a read-only and open-world operation, and the description adds substantial behavioral context beyond that: check-digit handling, logo constraints, scannability verification, output format (SVG/base64 PNG plus data URI), and a paid x402 cost. This is rich disclosure without contradicting the annotations.

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

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

The description is dense but front-loaded with the core purpose, then layers format support, special features, verification behavior, return format, and cost. Every sentence contributes useful information for this 11-parameter tool, with no filler.

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

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

With no output schema, the description fills the gap by specifying return values (SVG text, base64 PNG, data URI) and verification behavior. Combined with full schema coverage and annotations, an agent has everything needed to 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 the schema already documents all 11 parameters thoroughly. The description reinforces some parameter behavior (e.g., QR/DataMatrix colour and style options, logo URL requirements, check-digit logic) but adds little semantic meaning beyond what the schema provides, warranting the baseline 3.

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: generate a barcode or QR code. It enumerates supported formats and output types, making it clearly distinguishable from sibling read_barcode and other tools.

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

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

The description gives clear context for generation tasks (formats, output options, payment) and implicitly contrasts with reading barcodes via the sibling name, but it does not explicitly state when not to use it or name alternatives like read_barcode or lookup_product_code.

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

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

Annotations only declare readOnly/openWorld; the description adds offline operation, data provenance and licensing (GeoNames + DB-IP, CC BY 4.0), the precision ceiling (no street addresses), and — critically — the paid cost of $0.001 via x402. Cost and coverage limits are exactly the behavioral facts an agent must know before invoking.

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

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

A single dense sentence front-loads what the tool is and the mode-selection rule, then appends granularity and cost. No filler; every clause carries information (modes, sources, limits, price).

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

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

For a 7-parameter tool with no output schema, it covers input modes, result granularity, and cost. Minor gaps remain: no statement of what the response looks like or how `limit` defaults/behaves, and no rate-limit note, but the essential call-time facts are present.

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

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

Schema coverage is 100% so each parameter is already documented, but the description adds value the schema lacks: the mutual-exclusivity rule ('exactly one of'), the input->output mapping (ip yields country/region/city/lat,lon), an example query format, and the postcode+country pairing for precision.

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 ('offline geocoding') and immediately enumerates the four supported input modes, with the data sources named. It also differentiates scope from siblings by stating granularity ('city/place level; no street addresses'), which separates it from tools like location_report or resolve_name.

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

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

Gives clear operational context: use exactly one of ip, q, postcode, or lat+lon, with 'optional country filter' and 'reverse' semantics for lat+lon. It does not, however, name an alternative sibling tool or state when this should be preferred over location_report/resolve_name, 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds genuinely new behavioral context not in schema or annotations: the 100-resources-per-page pagination size and the 'Free' cost signal. It omits return format, but pagination and cost are useful.

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

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

A single tight sentence that front-loads the resource and scoping facts with zero filler. Every clause earns its place.

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

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

For a simple read-only, zero-required-parameter tool with full schema coverage and annotations, the description supplies the key missing detail (page size, cost). It could say more about what a resource is, but it is adequate to invoke correctly.

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

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

Schema description coverage is 100%, so the two parameters (page, topic) are fully documented in the schema. The description adds nothing beyond the schema about their semantics, 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 (browse the catalog) plus scope (100 per page, optionally by topic). An agent can tell this is a paginated catalog reader, though it does not explicitly differentiate itself from siblings like list_topics.

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?

'Optionally by topic' implies a filtering use case, giving some implied guidance. However, it never states when to use this over list_topics or other discovery tools, 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 and openWorldHint, so the safety profile is covered. The description adds genuinely non-redundant behavior: licence and attribution terms plus a pricing model ('Paid ($0.0001, x402)') and a free catalogue path, which an agent needs to know before invoking 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?

Two compact sentences, front-loaded with the resource and access modes, then the catalogue and pricing. The 'Static Knowledge Base:' prefix is mildly cryptic but the rest is dense with useful signal and 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?

No output schema exists, so the description carries some burden to describe returns; it discloses licence/attribution and cost but not the shape of the returned records or pagination semantics. It is adequate for a read-only fetch tool but leaves return-format gaps.

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 defines id, key, page, continent, and country_code in detail. The description's phrase 'by page, by id or by facet filter' only loosely maps to those parameters and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description names the resource (open, commercially reusable static datasets such as world cities, countries, ISHOB topics) and the access modes (by page, by id, by facet filter), making the retrieval intent clear. It lacks an explicit verb and does not name a distinguishing sibling, but the resource scope is specific enough to separate it from get_document or get_fulltext.

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

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

It implies three access modes (page/id/facet) and points to the /v1/datasets catalogue for discovering keys, which is useful context. However, it never states when to prefer this tool over alternatives like get_catalog_page or query_specs, so usage is only inferred.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds genuine non-schema behavior: this call is paid ($0.001 via x402), which an agent needs to know before invoking. It stops short of noting rate limits or failure modes on payment.

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

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

Two short sentences with no waste; the returned content is front-loaded and the cost caveat follows immediately. Nothing could be removed without losing information.

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

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

For a single-parameter, read-only paid lookup with no output schema, the description covers both what comes back and the payment requirement. It could add a sentence on when to prefer get_fulltext, but nothing essential is missing.

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

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

Only one parameter, and schema description coverage is 100%, so the schema fully documents the id format and its source tools. The description adds nothing beyond that, which is the expected baseline when the schema does the work.

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

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

Names a specific resource ('one resource') and enumerates the returned content: metadata, abstract, license, attribution. This differentiates it from siblings like get_fulltext and get_references. The verb is only implied ('Record ... for'), which keeps it 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?

No when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The id provenance (search_archive / get_catalog_page) appears only in the schema, not the description, so routing context is inferred rather than stated.

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

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

Annotations only cover read-only and closed-world semantics; the description adds genuinely new behavior: the result is section-structured, includes license metadata, and requires payment of $0.01 via x402. The payment requirement is the kind of trait structured fields do not express. It stops short of describing failure/rate-limit 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?

One compact sentence, front-loaded with what is returned, then license and cost. Every clause carries information and nothing is padded.

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

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

For a single-parameter, no-output-schema tool, the description covers output shape (sections, license) and the notable payment constraint. Missing only an explicit pointer to the id source workflow, which the schema partially 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% and the id parameter already documents its source (search_archive / get_catalog_page) and format example. 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 resource being retrieved ('one resource') and characterizes the payload ('structured full text (sections), with license'), which separates it from a plain text or reference fetch. It does not explicitly contrast with siblings like get_document or get_references, so an agent must infer the distinction.

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 paid/cost note ('Paid ($0.01, x402)') flags a meaningful usage consideration an agent should weigh before calling. However, there is no statement of when to prefer this over get_document, get_references, or extract_webpage, so routing is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context by disclosing a per-call charge and the x402 payment mechanism, but it never explains what x402 entails or what happens on payment failure, so the disclosure is a fragment rather than full guidance.

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

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

Two short sentences, front-loaded with the purpose and then the cost. Nothing is padded, though 'Paid ($0.002, x402)' is compressed to the point of being cryptic rather than purely economical.

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

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

With no output schema, the description must convey the return shape, and 'parsed reference list' is only a partial answer — no indication of fields, ordering, or whether references are limited/paginated. For a paid tool whose result is unstructured to the agent, this leaves real gaps.

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 'id' parameter is already documented with its source tools and an example. The description adds nothing about the parameter, so the baseline 3 for schema-covered parameters 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 resource ('reference list of one resource') and the modifier 'Parsed' signals the output is structured extraction rather than raw text, distinguishing it from get_fulltext or get_document. It stops short of explicitly contrasting itself with those siblings, so a 4 rather than a 5.

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

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

There is no when-to-use guidance, no prerequisite (e.g. that the id comes from search_archive/get_catalog_page, which only appears in the schema), and no mention of alternatives such as get_fulltext for the body text. The only operational note is that the call costs money.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by noting the counts are 'live' (current data, not cached) and that the call is free, but it says nothing about result size, ordering, or pagination.

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

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

Two short sentences, zero filler, with the resource description front-loaded ahead of the cost note. Nothing could be removed without losing information.

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

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

For a zero-parameter, read-only list tool with no output schema, the description covers what is returned (topics plus counts) and the cost. Minor gaps around ordering/truncation of results remain but are not critical for 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?

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb (List) and resource (knowledge topics) plus a scope qualifier (live resource counts), so an agent knows exactly what it gets back. It does not, however, distinguish itself from any sibling tool by name or category.

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 trailing 'Free' hints at a cost-free discovery call, but there is no statement of when to call this versus search_specs, query_specs, or the get_* siblings. An agent must infer that this is a browsing/discovery entry point.

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

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

With readOnlyHint and openWorldHint already declared, the description still adds material behavioral context the annotations lack: this is a paid call ($0.01, x402) and inputs can be either a place name or lat/lon with automatic reverse geocoding. It does not cover failure modes, rate limits, or how hours interacts with data 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 purpose followed by a dense but scannable enumeration of returned data, then a short applicability sentence and the cost note. Every clause carries information; it is long but not padded, though the parenthetical lists make it slightly heavy.

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 must summarize returns, and it does so thoroughly (weather dimensions, astronomical data, country facts). The main residual gaps are the shape/format of the response and how partial input (e.g., only q, or only lat) is handled.

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 real meaning: it clarifies q and lat/lon are alternative input modes (forward vs reverse geocoding) and that hours defines the weather forecast window. That is more than the schema's 'Forecast window' phrasing 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?

The description states a concrete composite resource and enumerates exactly what it returns: place resolution/reverse geocoding, hours-ahead weather risk, local time, sunrise/sunset/daylight, and country facts. The phrase 'in one call' implicitly positions it above the narrower siblings geocode and weather_risk, but neither sibling is named, so an agent must infer the boundary 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?

'For logistics, travel, events and drone planning' gives clear use-case context for when this bundled report is appropriate. However, it never states when to prefer the cheaper single-purpose siblings (geocode, weather_risk) instead, and gives no exclusions or prerequisites.

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 genuinely useful behavior beyond that: it is a paid call ($0.001, x402), it draws from external open databases, and wrong check digits are reported with the correct digit.

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 the core lookup action and code formats before the data-fetch and pricing details. Every clause carries information, though the long enumeration of formats and databases pushes it toward verbosity.

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

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

With no output schema, the description compensates by naming the returned fields (name, brand, quantity, categories, image, labels, Nutri-Score, or title/authors/publisher/cover). Pricing and open-world sourcing are disclosed, leaving little an agent would need to call it correctly.

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

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

Schema coverage is 100%, so both parameters are already fully documented in the schema. The description restates the lookup flag's effect but adds no new syntax or format detail beyond the schema, which is the expected baseline-3 situation.

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

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

States a precise verb and resource ('Look up a product barcode number') and enumerates the exact code families handled, plus the downstream data fetch. This clearly separates it from siblings like read_barcode and generate_barcode, which imply different operations.

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: validate/convert vs. fetching product data, with the 'lookup=false' path spelled out. It does not explicitly route the agent away from sibling tools such as read_barcode or generate_barcode, so the when-not guidance is implicit rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description earns credit for adding cost information ('Paid ($0.0002, x402)'), clarifying that a down target is a valid result, and detailing the returned redirect chain, security headers, and TLS certificate fields. It does not cover rate limits, timeouts, or authentication mechanics beyond the mention of x402.

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 then lists outcomes, validity of down targets, and pricing in three tight sentences. The first sentence is long but every element earns its place, and there is no filler.

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

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

With no output schema, the description carries the burden of explaining return values and does so by listing HTTP status, response time, redirect chain, headers, security headers, and TLS certificate details. It also notes the paid cost, though it leaves timeout/error behavior and exact auth flow 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. The description repeats what the schema already documents for check_ssl and follow_redirects and does not explain method selection (HEAD vs GET) or add syntax beyond the schema fields.

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 clear purpose: an uptime/API health check for a URL, and enumerates what it reports (HTTP status, response time, redirect chain, headers, TLS certificate). This distinguishes it from most siblings, though it does not explicitly name alternatives like site_speed or site_audit.

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 opening 'Uptime / API health check' and the note that 'A down target is a valid answer,' but there is no explicit when-to-use guidance or comparison to sibling tools such as site_speed or site_audit. An agent can infer the context, but alternatives are not 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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes beyond them by disclosing the cost and payment mechanism ('Paid ($0.001, x402)') and the return payload ('with source document and license'), which the agent needs before calling. It stops short of describing pagination or result caps beyond what the limit parameter implies.

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

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

Two compact sentences with no filler. The heavy filter list makes the first sentence slightly run-on, and the critical payment caveat is deferred to the end rather than front-loaded, but overall it is efficient.

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

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

For a paid, read-only 7-parameter lookup with no output schema, the description covers cost, filters, and returned fields, which is most of what is needed. It omits the crucial routing information relative to sibling search_specs and says nothing about result pagination, leaving a gap for an agent choosing between spec-retrieval 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 description coverage is 100%, and the schema spells out examples and constraints for max, min, unit, family, quantity, etc. The description only loosely maps to the quantity/family/unit/range parameters without adding syntax or precision 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 clearly identifies the resource (a structured specification table) and enumerates the filter dimensions (quantity, unit family, unit, value range) plus the payload it returns (source document and license). However, it never differentiates this tool from the sibling search_specs, so an agent cannot tell which one to select from the description alone.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the obvious alternative search_specs. The agent must infer usage purely from the name and filter list.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the pricing model ($0.001, x402 paid), the billing rule (no code found = not charged), and robustness behavior (finds every code even rotated, small or inverted). That is exactly the operational context 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-loads the core purpose and capabilities, and nearly every clause carries information (formats, robustness, return fields, billing). It is a dense run-on paragraph, but little of it is filler, so only minor trimming is warranted.

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

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

With no output schema, the description compensates by enumerating the return fields (text, format, position, meaning) and the semantic decoding (URL, Wi-Fi, vCard, e-mail, phone, location, crypto URI, GTIN). Combined with input limits and billing terms, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, and the description adds no syntax or format detail beyond restating supported formats. Baseline 3 applies 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 (read) and resource (barcodes/QR codes) plus the full set of supported symbologies, which cleanly separates it from the sibling generate_barcode. An agent can identify the decode direction and the input types without opening the schema.

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

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

Gives clear usage context: image input via URL or base64, and typical scenarios (phone photos, receipts, labels, screenshots), including hard cases like rotated, small or inverted codes. It never names an alternative or states when not to use it (e.g. encoding with generate_barcode), 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 only declare readOnly and openWorld; the description adds substantive operational context beyond them: robots.txt is respected, nothing is stored, social networks are not scraped, and the call is paid ($0.0003 via x402). The payment requirement is exactly the kind of cost/auth disclosure an agent needs before invoking.

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

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

Core purpose is front-loaded in the first clause, followed by tight sentences on discovery, compliance, and cost. The long enumeration of feed formats and output fields is dense but each element carries selection-relevant information, so it is efficient rather than padded.

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

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

With no output schema, the description carries return-value burden and does so by naming the JSON item fields an agent will receive, plus cost and compliance behavior. It omits pagination/'limit' semantics and error behavior, so it is strong but not exhaustive.

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 'url' and 'limit' are already documented in the schema. The description adds no extra syntax, format, or defaulting guidance for either parameter, so baseline 3 is correct. The field list it provides ('title, link, ISO dates...') describes output, not inputs.

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

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

States a specific verb ('Read') and resource (published RSS/Atom/JSON feeds) and enumerates the concrete source types (blogs, news, podcasts, Reddit, Mastodon, YouTube). This clearly separates it from nearby siblings like extract_webpage or site_metadata without needing to open any schema.

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

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

Gives clear context for use (feed URL or an HTML page that advertises a feed) and a scope exclusion ('social networks are not scraped'), which tells the agent when this will not work. It never names a competing sibling tool or says what to use instead for non-feed pages, so it stops short of a full 5.

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

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

Annotations cover readOnlyHint and openWorldHint, yet the description adds real value beyond them: the download link is private and expires in 24 hours, external resources are never fetched (inline data: images only), and the call costs $0.001 via x402. Only the return/pagination specifics are left unstated.

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

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

A single dense sentence front-loads the verb and resource before qualifiers, and every clause carries information (formats, page sizes, cost, security). It is packed with parentheticals but not padded.

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

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

With no output schema, the description carries the return-value burden and does so — a private download link valid 24 hours — while also covering supported formats, page sizes, CSS, security posture, 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 description coverage is 100%, so all six parameters (css, title, format, filename, markdown, page_size) are already documented. The description reinforces formats, page sizes, and CSS but adds little syntax or default information beyond the schema, matching the baseline 3 for high coverage.

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

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

States a concrete verb and resource — rendering Markdown into PDF/DOCX/HTML — and enumerates the input features (tables, code, lists, headings) and output variants. No sibling (extract_tables, get_document, screenshot) does document rendering, so the scope is unambiguous.

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

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

Usage is implied by the description (render Markdown to a document format) and the cost/format notes help selection, but there is no explicit when-to-use or when-not-to-use guidance and no alternative tool named. Adequate but leaves the agent to infer context.

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

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

With annotations only declaring readOnlyHint and openWorldHint, the description carries real behavioral weight: the $0.05 x402 charge, the pre-payment check, the free 'not_covered' 404 failure mode, and the licensing rule (abstracts only for CC0/PD/CC BY/CC BY-SA, metadata+link otherwise). These are non-obvious traits the agent could not infer from structured fields.

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

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

The core purpose is front-loaded in the first clause, and the follow-on clauses all carry information (licensing behavior, pricing, failure mode) rather than filler. The single run-on paragraph packed with semicolons is dense but not wasteful.

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

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

There is no output schema, but the description still specifies the return shape (authors, year, venue, DOI, citations, conditional abstracts, numbered synthesis citations), the cost, and the failure case. For a paid, no-output-schema tool, nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents query, year_from, max_papers, synthesize, and include_live. The description adds narrative context for synthesize ('cites the papers as [n]') and include_live ('filled with a live search... when the archive has fewer papers'), but adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb+resource ('Research brief on any topic') and enumerates exactly what the brief contains: archive papers plus live search, per-paper metadata, and an AI synthesis. It is clearly distinguishable from siblings like search_archive, search_specs, and get_fulltext, which return raw results rather than a synthesized brief.

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

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

It implies the use case ('one call') and describes the fallback condition (free 404 if nothing is found anywhere) and the payment trigger, but never states when to prefer this over search_archive or get_fulltext, which are the obvious alternatives. Usage is inferable rather than explicit.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the paid x402 cost ($0.001), the no-charge-on-404 policy, and that address-direction results are verified to resolve back to the same address. These are exactly the operational details an agent needs before committing 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?

Dense and front-loaded, leading with the dual direction of resolution before enumerating cost and edge cases. The parenthetical list of profile records is somewhat long but conveys concrete return fields, so it largely earns its space.

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

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

With no output schema, the description carries the burden of explaining return values and does so thoroughly for both directions, plus cost and error semantics. An agent has everything needed to call it correctly and interpret results.

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 meaning by mapping each parameter to a distinct output shape (name -> address + profile records + primary-name flag; address -> primary ENS + primary Basename). It also reinforces the mutual exclusivity of the two parameters.

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

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

States a specific verb (resolve) and resource (ENS names and Basenames) with the bidirectional scope spelled out, including the exact outputs for each direction. It is immediately distinguishable from siblings like domain_intel or wallet_report.

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

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

Clearly defines applicable inputs (.eth, *.base.eth, subnames, offchain/CCIP-Read) and the failure condition (unknown = 404, not charged), which gives an agent strong context for when the tool applies. It stops short of naming an alternative sibling or an explicit when-not-to-use-this-tool rule.

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

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: robots.txt respected, every request SSRF-guarded, nothing stored, and a paid cost model ($0.001, x402). These are operationally critical traits an agent cannot infer from the annotations.

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

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

A single dense sentence leads with the core action and then layers format, limits, safety, and cost via semicolons. Every clause carries information; nothing is wasted.

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

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

For an 8-parameter tool with no output schema, the description covers what it does, the return encoding, size constraints, safety guarantees, and billing. 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, but the description adds real value beyond the schema: the 1920x1920 viewport ceiling with 1920x1080 default and the 8000px full-page limit are constraint details absent from the parameter definitions.

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

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

States a precise verb+resource ('Render a public web page in headless Chromium... return a screenshot') and specifies the output format (base64 PNG/JPEG/WebP) and audience (vision models). This distinguishes it from text-returning siblings like extract_webpage and extract_tables.

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

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

The phrase 'for vision models' implies the intended use case, but the description never states when to pick this over siblings such as render_document, extract_webpage, or get_catalog_page, nor any exclusions. Usage is implied rather than explicit.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds matching semantics ('all words must match', i.e. AND behavior) and that the operation is free, but says nothing about result format, ordering, or pagination beyond the schema's limit.

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 terse fragments, front-loaded with the verb and resource, with zero padding. The telegram style is efficient, though the parenthetical and 'Free' fragment are slightly clipped rather than fully formed 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?

For a 7-parameter search with no output schema and safety already covered by annotations, the description conveys scope and match semantics but omits return shape, ordering, and result-volume expectations. Adequate but with visible gaps given the schema's richness.

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

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

Schema description coverage is 100%, so every parameter (limit, topic, license, year ranges, fulltext) is already documented in the schema. The description adds only the AND-matching semantics, which the query parameter description also states, so this sits at the prescribed 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 ('Search') and resource ('the ISHOB archive'), and scopes it by naming the searched fields (titles, keywords, authors). It does not, however, differentiate itself from the similarly named search_specs sibling, so an agent must infer which archive/search surface applies.

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 statement of when to use this tool versus alternatives such as search_specs, get_dataset, or get_document. 'Free' gestures at cost but is not an actionable usage condition, leaving the agent to guess at fit.

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

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

Annotations only cover safety (readOnlyHint, openWorldHint), so the description carries extra burden. It discloses the paid cost ($0.001, x402) and that numeric constraints are matched against extracted values/ranges/tolerances/units — useful behavioral context not present in any structured field. No contradiction with annotations.

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

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

Three short, front-loaded sentences with no filler; the core search capability leads and cost/payment mode is a terse trailing note. Slightly clipped (the x402 mention is bare), but efficient overall.

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

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

No output schema, so the description could reasonably explain result shape, but it does not. It covers search scope and pricing adequately, yet leaves the query_specs disambiguation and return format unaddressed for a 5-parameter search tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only adds semantics for the query parameter (numeric constraint matching), saying nothing about limit, topic, category, or year_from, which remain defined solely by 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 ('full-text search over abstracts and full texts') and adds a distinguishing scope detail: extracted technical specifications and numeric-constraint matching. However, it does not differentiate itself from the sibling query_specs, which appears to be the closest functional neighbor, so sibling-level ambiguity remains.

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

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

It implies search usage ('Numeric constraints like "50 Nm" are matched') but never states when to prefer this over query_specs, get_fulltext, or get_document, nor any prerequisites or exclusions. With a near-identical sibling name in the toolset, the absence of routing guidance is a real 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?

The description clearly describes a mutating operation: it schedules an alarm, causes future webhook POSTs, and charges the caller. The annotations declare readOnlyHint=true, which directly contradicts the described behavior of creating state and incurring cost. This is a serious annotation 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?

The description is front-loaded with the core action and packs timing, retry, signing, cost, and management endpoints into a compact paragraph. It is dense but not wasteful. Slight readability cost from being a single long paragraph rather than broken into sentences or bullets.

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 complex, stateful tool with no output schema, the description covers timing bounds, retry behavior, HMAC signing, pricing, and how to check or cancel an existing alarm. It does not explicitly state what set_agent_alarm returns (for example, an alarm id), which is a gap given there is no output schema. The annotation contradiction also reduces confidence in the overall completeness.

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 input schema already documents every parameter. The description adds some useful context about signing and retry timing, but it also mentions a signing_secret that is not an input parameter, which may confuse parameter semantics. Baseline 3 is appropriate when the schema does most of the work.

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

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

The description states a specific verb and resource: scheduling a signed webhook to wake an AI agent later. It distinguishes the tool from all listed siblings, none of which concern delayed webhook alarms. An agent can identify the tool's purpose 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 gives context for use (schedule a webhook for later, check status for free, cancel for free, charged only when accepted), but it never states explicit when-to-use or when-not-to-use conditions versus alternatives. There are no sibling tools with overlapping functionality to route against, so the guidance is implied rather than explicit.

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

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

Annotations only declare readOnlyHint/openWorldHint; the description adds substantial context beyond them: no broadcast occurs, the paid x402 cost, chain-specific simulation backends (eth_simulateV1 vs simulateTransaction), chain support (7 networks), and the shape of the result including revert reason and risk level.

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

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

Front-loads purpose and effect ('what leaves and enters the wallet'), then mechanics, then cost. The single dense enumeration is entirely informational — no filler, no restatement of the title 'simulate tx'.

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 7-parameter, no-output-schema tool, the description supplies everything an agent needs: supported chains, the EVM-vs-Solana invocation split, that broadcast does not happen, cost, and the returned fields including failure signalling via revert reason.

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, but the description adds real semantics the schema lacks: which parameters belong to the EVM raw-call path (from, to, data, value) versus the Solana path (base64 transaction), and that Solana payloads may be unsigned.

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 ('Simulate a transaction before signing it') and enumerates the exact outputs an agent gets (balance deltas, approvals, revert reason, gas/fee, risk level). This clearly separates it from siblings such as explain_transaction (post-hoc analysis), swap_route (routing) and token_flows without needing to open any schema.

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

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

Gives clear triggering context: pre-signing, with an explicit 'Nothing is broadcast' exclusion and the paid/price model ($0.0015, x402). It does not name a sibling to use instead when the transaction is already on-chain (e.g. explain_transaction), so it stops short of full when/when-not 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 only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: robots.txt is respected, nothing is stored, one real browser load is performed, and the call is paid ($0.02, x402). Cost and data-handling disclosures are exactly the kind of behavioral detail an agent needs before invoking.

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

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

Front-loaded with the primary deliverable and dense but well-punctuated with semicolons rather than filler. It is on the long side and somewhat run-on, but nearly every clause conveys a distinct capability or constraint.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly: it names the grade, the four scores, the issue-list-with-fix format, and each underlying check. An agent knows what it will receive and what the call costs.

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, device, and screenshot are already fully documented in the schema. The description echoes the optional screenshot and browser-load behavior but adds no format or constraints beyond what the schema provides, matching the baseline for high-coverage schemas.

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 ('Full website audit in one call') and enumerates the exact scope: A-F grade, four dimension scores, and all issues with fixes. This clearly distinguishes it from narrower siblings like site_speed and site_metadata by emphasizing the comprehensive one-call coverage.

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 'full audit in one call' framing and the cost/mechanism note, but the description never explicitly says when to choose this over site_speed or site_metadata, nor does it state prerequisites or exclusions. Adequate but no 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 only declare readOnlyHint and openWorldHint. The description adds materially new behavior: robots.txt is respected, nothing is stored, only the head is fetched (no full DOM download), and the call is paid at $0.0002 via x402 — cost and compliance details an agent cannot get from the annotations.

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

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

One dense sentence leads with the action and payload, then parenthesizes the operational constraints. No filler, no repetition of the title, and the most decision-relevant facts are front-loaded.

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

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

For a one-parameter tool with no output schema, the enumerated extraction targets effectively describe the return contents, and the constraints (head-only, robots-respecting, no storage, priced) cover the operational picture. Nothing needed to call it correctly is missing.

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

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

There is a single parameter (url) with 100% schema description coverage ('Public http(s) page URL'), so the schema already carries the semantics. The description adds no format or constraint beyond what the schema states, 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?

Names a specific verb (Extract) and a precisely enumerated resource set (title, meta tags, OpenGraph, Twitter card, canonical/icons/feeds, JSON-LD), scoped to the <head>. This distinguishes it from sibling page tools like extract_webpage, site_audit and site_speed without the agent opening any schema.

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

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

The '<head> only (no full DOM download)' constraint implies when this tool is preferable to a full-page extractor, but no sibling or alternative is named and there is no explicit when-to-use statement. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior context beyond them: robots.txt is respected, the run is unthrottled and lab-based, and it is a paid x402 call at $0.001 — the cost/auth detail is important for an agent deciding whether to invoke it.

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

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

Front-loads the resource and method, then compresses metrics into a single dense clause. Every sentence carries information (metrics, methodology, cost, robots), though the metric enumeration is slightly dense.

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

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

There is no output schema, so the description carries the burden of describing returns — it does list the metrics and rating bands (good/needs-improvement/poor). With annotations covering the read-only nature and cost/robots disclosed, this is nearly complete, short only of pagination or response shape details.

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

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

Schema coverage is 100% and both parameters (url, device enum) are already documented in the schema. The description mentions 'mobile or desktop' but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific resource (page speed / Core Web Vitals) and the exact method (real headless-Chromium load) plus the metrics returned. It proactively distinguishes itself from adjacent approaches by stating 'not Lighthouse, not field data', so an agent can identify it 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 clarifies the measurement methodology (lab run, unthrottled, Cloudflare network) which aids selection, but it never states when to prefer this over siblings like site_audit or site_metadata. Usage is implied rather than routed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description reinforces this ('Quotes only; ISHOB never sends transactions'), which is consistent rather than contradictory. It adds substantial context beyond the annotations: the aggregator source and liquidity breadth, the exact output fields (output amount, slippage-protected minimum, USD value change, gas, hops), the conditional unsigned-transaction behavior, and the payment model ($0.001, x402).

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 in the first sentence, followed by the output list, the conditional `sender` behavior, the read-only boundary, and pricing. It is dense but every clause carries information; the parenthetical detail is slightly heavy, keeping it from a 5.

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 compensates by enumerating the returned fields (output amount, slippage-protected minimum, USD value change, gas, hops). The conditional `sender` behavior, the read-only guarantee, and the payment requirement are all disclosed, leaving no material gap for an agent to call this 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 the baseline is 3. The description adds real meaning on top of the schema by explaining the effect of `sender` (unsigned ready-to-sign transaction plus allowance check) and by surfacing slippage protection as a returned quantity tied to slippage_bps, letting the agent understand parameter consequences without inferring them.

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 (best DEX swap route and quote) and names the underlying mechanism (KyberSwap aggregator, 400+ liquidity sources, split routes) across six named chains. This is clearly distinguishable from siblings like simulate_tx, token_audit, or wallet_portfolio because it is explicitly a quote/route tool.

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

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

Gives clear conditional usage: 'With `sender`, also an unsigned ready-to-sign transaction plus the ERC-20 allowance check.' The line 'Quotes only; ISHOB never sends transactions' tells the agent this is a read/quote path, not execution. It does not explicitly name an alternative (e.g. simulate_tx) for pre-execution simulation, so it stops just short of full when/when-not guidance.

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

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

Annotations only say readOnly and openWorld; the description adds material traits beyond that: it is a paid call ($0.001 via x402), it aggregates GoPlus data plus the provider's own on-chain checks, and it returns severity-ranked flags with a risk level. It stops short of saying whether the payment must be settled first or what failure/latency looks like.

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 what-and-where is front-loaded, then the check inventory, then the cost and return shape. It is dense and mostly earns its length, though the chain list is enumerated both here and in the enum, which is 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?

With no output schema, the description takes on the burden of describing returns and does so at a high level ('severity-ranked flags and a risk level'). Data provenance and pricing are disclosed. It is slightly thin on how a caller should act on the result or on latency/error behavior, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and both parameters are documented there, so the schema carries the load. The description's chain list and '0x... / base58 mint' phrasing merely restate the enum and schema text without adding new semantics, so baseline 3 applies.

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

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

States a specific verb and resource ('Token safety & scam check') and enumerates exactly what is audited (honeypot simulation, taxes, mint/blacklist/pause privileges, LP lock, holder concentration, proxy slots, Token-2022 extensions). It never names or contrasts the nearby siblings token_report and token_verdict, so an agent must infer the division of labor 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?

The content implies a pre-trade / due-diligence use case, but there is no explicit when-to-use, when-not-to-use, or alternative routing. An agent can guess the intent from the listed checks, which is exactly the 'implied usage' level.

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 and openWorldHint, and the description adds genuinely new behavioral context: it is a paid call ($0.01, x402) and enumerates the returned analytics including wash-trading signals. It does not mention rate limits or latency, so not a full 5, but it meaningfully exceeds the annotation baseline.

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

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

Core purpose is front-loaded in the opening clause, and the sentences are dense with no filler. The return-value enumeration is long but earns its place given there is no output schema.

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

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

With no output schema, the description thoroughly explains what comes back (volumes, net flow, unique buyers/sellers, largest trades with tx hashes, organic-activity score). Combined with the chain and payment details, an agent has what it needs to call correctly; only pagination/limits are 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 both enums are documented, so the schema already carries parameter meaning. The description only restates the chain list and windows, adding no syntax or format detail beyond the structured fields — the expected baseline when 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 ('who is buying and selling a token'), and specifies scope as on-chain transfers split into DEX buys, sells and wallet transfers. This is distinguishable from siblings like token_audit, token_report, swap_route and wallet_portfolio without opening any schema.

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

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

Provides clear context ('right now', the 1h/6h/24h windows) that implies when the tool is useful, but never names an alternative or states when NOT to use it versus token_report/token_verdict. Usage is implied rather than explicitly routed.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true). The description adds genuinely useful context beyond them: it is a paid tool ($0.05 via x402), it depends on an external provider (GoPlus Security), and it performs live sell tests, which implies latency and external-data dependency. It does not mention rate limits or expected response time.

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 value proposition (score + verdict) before listing components, chains, and cost. Every clause carries information, though the component list is somewhat compressed and could be broken out for scanability.

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

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

With no output schema and only two annotations, the description does much of the work: it explains the returned verdict categories, that deductions are explained, the chain coverage, and the payment model. It stops short of describing the response shape or failure modes, but is otherwise sufficient 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% and both parameters are documented in the schema, including the enum of supported chains. The description's chain list merely restates the enum, so it adds no syntax or format detail beyond structured data; baseline 3 is appropriate.

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

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

States a specific outcome ('0-100 safety score and verdict') and enumerates the components it bundles (GoPlus audit, contract scan, liquidity, live sell tests). It implicitly positions itself as a superset of the similar siblings token_audit and token_verdict, but never names them or explicitly says how it differs, so the differentiation is inferred rather than stated.

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?

'Token due diligence in one call' clearly frames the use case and the multi-chain scope is listed. However, it gives no exclusions or named alternatives (e.g. 'use token_audit for the cheap check, this for full diligence'), so the agent must infer when the comprehensive, paid version is justified over lighter 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds substantial context beyond them: deterministic rule-based behavior ('same token, same answer'), the underlying data sources (GoPlus, on-chain checks, DEX liquidity), and a cost/access constraint ('Paid ($0.01, x402)'). This is real behavioral disclosure, though rate limits and latency are unaddressed.

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 and answer format, then supporting facts, sources, and cost. Dense but every fragment carries information. The chain list and payment note are slightly list-like rather than prose, but nothing is redundant.

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

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

With no output schema, the description carries the burden of describing returns, and it does so concretely (verdict tiers, score, top 3 reasons, good signals, key facts like honeypot/taxes/liquidity/holders/owner). Supported chains and the payment requirement are stated. Only the precise response structure and error/pagination behavior are left unspecified.

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

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

Schema description coverage is 100%, so chain, address, and card are already documented in the schema. The description reinforces this by listing the supported chains and explaining that the optional card yields a 1200x630 SVG, but adds little syntactic or semantic detail beyond what the schema states. Baseline 3 applies 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?

The opening question 'Should I touch this token?' plus the explicit output list (verdict, 0-100 score, top 3 reasons, good signals, key facts) makes the verb and resource unmistakable. It clearly produces an assessment of a token. However, it never distinguishes itself from the sibling tools token_audit and token_report, so an agent must guess which one to pick.

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 touch this token?' implies the decision-making context (should I interact with this token), which is genuine implied usage. But it offers no explicit when-to-use versus token_audit/token_report, no exclusions, and no prerequisites beyond the payment note. 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 already declare readOnlyHint and openWorldHint, but the description adds valuable context beyond that: it states the tool is paid ($0.001, x402), specifies the data source (on-chain DEX pools), and details chain/token coverage and limitations (EVM vs Solana, up to 20 extra tokens). This helps the agent understand cost and data freshness, though it does not mention rate limits or authentication requirements.

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 then concisely details coverage, pricing, and data sources. It uses semicolons to pack multiple facts efficiently, though the single long sentence could be slightly split for readability. Every sentence contributes 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 four parameters, no output schema, and annotations that cover read-only and open-world aspects, the description is fairly complete: it explains what data is returned (balances, holdings, USD values, totals), data sources, cost, and chain/token coverage. It does not elaborate on the min_usd parameter or response format, but those are either covered by the schema or not critical for 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 schema already documents all four parameters fully. The description reiterates some details (e.g., 'up to 20 tokens you pass', chain list) but adds no new syntax or semantics beyond what the schema provides, so a 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?

The description clearly states the tool's purpose: retrieving a multi-chain wallet portfolio with native balances, token holdings, USD values, and per-chain totals. It specifies the scope (EVM vs Solana chains, token coverage) but does not explicitly differentiate from sibling tools like wallet_report or token_report, leaving the agent to infer the distinction.

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 provides no guidance on when to use this tool versus alternatives. It describes what the tool does but does not mention conditions for use, exclusions, or sibling tools, so the agent must infer usage from the purpose alone.

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), and the description adds meaningful context beyond them: the GoPlus Security data source, the exact verdict taxonomy (clean/caution/high-risk/flagged/incomplete), and the paid x402 pricing ($0.03). It does not disclose latency, rate limits, or failure behavior on partial chain coverage, 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 core purpose and packed with useful detail (data source, verdicts, pricing) in minimal space. The opening clause runs long, but nearly every element earns its place and nothing is filler.

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

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

With no output schema, the description carries the return-shape burden well by enumerating the main output sections and the verdict values. It leaves minor gaps around the 'incomplete' verdict's cause and Solana limitations, but is otherwise sufficient for an agent 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?

Schema coverage is 100%, so both parameters are already documented. The description reinforces the chain behavior by listing supported networks and noting 'Solana: holdings only', which adds a semantic nuance, but it does not go beyond what the schema's chain description already conveys — the baseline 3 for full coverage 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 resource and scope — a combined wallet risk and activity report — and enumerates exactly what it returns (reputation, approvals, scam tokens, portfolio with USD values). This lets an agent distinguish it from siblings like wallet_portfolio, token_audit, and token_report without opening any schema.

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

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

Gives clear situational context: 'vet a counterparty before you transact'. This tells the agent when the tool applies. However, it never names an alternative or a when-not-to-use condition (e.g. use wallet_portfolio for holdings only, token_audit for a single token), so routing is left partly 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the upstream data source and license (MET Norway, CC BY 4.0), that the flags are heuristics rather than safety advice, that thresholds are returned alongside the flags, and that invocation is paid ($0.001, x402). The cost and reliability caveats are exactly the extra context an agent needs; only return shape/pagination is unaddressed.

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

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

Three dense sentences, front-loaded with what it returns and followed by the two things that most affect an agent's decision to call it: heuristic caveat and price. No filler clauses.

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

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

With no output schema, the description correctly compensates by naming the returned flags and their categories (event_risk low/moderate/high) and stating thresholds are included. Coverage is strong; actual threshold values and units are still unknown until invocation, which is a minor gap.

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

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

Schema coverage is 100%, with lat/lon ranges and the hours window already documented in the schema, so the baseline is 3. The description adds no syntax or format detail beyond noting that the hours window scopes the flags, which is already the schema's wording.

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

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

The description states a specific verb+resource (current weather and hourly forecast for a lat/lon) and then enumerates the derived outputs (drone_safe, event_risk, rain_expected, frost_risk, high_wind). No sibling tool competes in this domain, and the combination of raw forecast plus decision flags is unambiguous.

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

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

Usage is implied by the input (supply a lat/lon and get forecast + risk flags) but there is no explicit when-to-use/when-not guidance, no alternative routing, and no statement of when the heuristics are or aren't appropriate beyond the disclaimer. It is adequate but leaves the agent to infer the triggering conditions.

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