Stormap

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

Annotations only declare readOnlyHint and openWorldHint, so the description must carry the rest — and it does: it names the remote artifacts fetched (/.well-known/ucp, /.well-known/acp.json, MCP server card) and states the return shape (0-100 score, readiness level, prioritized fix list). It stops short of noting fetch limits or how unreachable pages are handled, which keeps it below a 5.

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

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

The motivating question is front-loaded, followed by a dense but scannable enumeration of checks and the return contract. It is long, but nearly every clause maps to a distinct capability, so little is 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 compensates by spelling out the result fields (score, level, prioritized fixes) and the full audit surface. For a single-parameter, read-only audit tool, an agent has everything needed to call it and interpret the answer.

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

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

Schema coverage is 100% and the single 'url' parameter already documents both accepted forms with examples. The description reinforces that any online store or product page is in scope ('AI bot access to product pages'), adding light interpretive value but no syntax beyond the schema.

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

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

The description opens with a concrete question-and-verb framing ('Audit whether an online store is ready for AI shopping agents') and then enumerates the exact signals checked (bot access, Product structured data, policy pages, sitemap/feed, platform detection, .well-known protocol files). That specificity separates it from siblings like check_ai_crawler_access (single-signal) and ai_visibility_score (visibility, not commerce readiness), even though no sibling is named.

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

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

Usage context is implied by the audit scope, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as check_ai_crawler_access, ai_visibility_score, or generate_ai_robots_txt, which overlap with parts of this check. An agent can infer the intent but must guess the boundary.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: the scoring scale, the checklist dimensions, the nature of the output, and the non-obvious rule that blocking bulk training crawlers is treated as a policy choice and does not lower the score. It stops short of stating rate limits, latency, or whether pages are cached, so it is strong but not exhaustive.

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

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

It is a single dense sentence with a front-loaded purpose followed by a colon-separated output list, and every element (checks, fix list, crawler policy) carries information. It is longer than strictly necessary, but there is no filler or redundancy, which keeps it efficient rather than bloated.

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 present, the description correctly compensates by describing what comes back: score, grade, per-check pass/fail, and a prioritized fix list. Combined with the crawler-policy caveat, an agent knows what it will get and how to interpret it; only minor operational details (auth/public-URL requirements, limits) are absent.

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

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

Schema coverage is 100% and the single 'url' parameter already carries a description with concrete examples of both domain and full-URL forms, so the burden is on the schema rather than the description. The description adds nothing about URL normalization, redirects, or whether the target must be publicly reachable at call time; 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 a specific verb-and-resource combination ('score how well AI assistants can find, read and cite a public web page') and enumerates the exact outputs produced (0-100 score, letter grade, pass/fail checks, prioritized fix list). It is immediately distinguishable from narrower siblings like check_ai_crawler_access or generate_ai_robots_txt, which cover only one slice of the 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?

The scenario ('AI search / GEO / AEO audit' of a public web page) is clearly implied, which is enough for an agent to know when this fits. However, there is no explicit when-not guidance and no pointer to alternatives such as check_ai_crawler_access for robots.txt-only questions, so routing between the overlapping siblings 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 only cover readOnlyHint and openWorldHint; the description adds real behavioral context beyond them: what the response contains, the adaptive scoring criteria, the depth-2 sub-idea expansion, and the honest caveat that scores are quick model estimates not research. It does not say whether the map_url result is persisted or how it is shared, which keeps 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?

One dense paragraph, roughly 110 words, front-loaded with purpose before mechanics and caveat. Every clause carries information, though the long criteria parenthetical makes it slightly run-on.

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

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

No output schema exists, and the description fully covers the return surface: scored ideas sorted best-first, optional sub-ideas at depth 2, and a map_url for follow-up work. An agent has everything needed to call it correctly and describe the result.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: it spells out which scoring criteria each kind of brainstorm produces and reinforces the depth-2 behavior and best-first ordering. The mode enum's individual values are left to the schema, so it does not fully compensate on every parameter.

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

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

States a specific verb and resource (brainstorm scored ideas for a topic) plus concrete scope: scored 1-10 on three criteria, overall score, sorted best first. It is immediately distinguishable from every sibling, which are all trust/check/score tools unrelated to idea generation.

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 mode examples ('for business ideas: market size...; for problem solving: impact, feasibility...') and the depth tradeoff, and the score-quality caveat steers the agent appropriately. However there is no explicit when-to-use/when-not statement and no named alternative, so the routing guidance 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, and the description adds genuinely useful behavioral context: which access-control source is consulted (robots.txt), which signals drive the score, and that the score is 0-100 with a findings list. It stops short of noting rate limits, caching, or failure behavior on unreachable URLs.

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 that front-loads the core purpose and then the output shape; the parenthetical crawler/signal lists are long but each item is informative. No filler sentences, though the readability clause slightly crowds the primary crawler-access purpose.

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 carries the return-value burden by naming the 0-100 score and findings list. Combined with a fully documented single parameter, an agent has enough to call it correctly; only failure/timeout behavior is unaddressed.

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

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

The single 'url' parameter is fully documented in the schema (100% coverage), including an example, so the baseline of 3 applies. The description adds only the constraint that the URL must be public, which is marginal beyond the schema.

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

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

The description states a specific verb and resource (check crawler access for a URL per robots.txt) and enumerates the exact crawlers and readability signals examined. It is clearly distinguishable from siblings like read_url (fetches content) and generate_ai_robots_txt (produces a file).

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 name and content but never stated: no 'use this when...' guidance, no conditions for choosing it over read_url or ai_visibility_score. It also gives no prerequisites (e.g., that the page must be publicly reachable).

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 adds important behavioral detail beyond that: it will 'never pays or signs anything' and it lists the exact categories of evidence used to form a verdict. This goes beyond the structured annotations and is especially useful in a payment-safety context.

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

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

The description is front-loaded with the core question and verdict output, then lists the evidence sources in a compact colon-delimited structure. Despite its length, every clause describes a relevant check or safety property, and there is no redundant filler.

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

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

For a complex, read-only verification tool with no output schema, the description explains the return shape (verdict plus reasons) and enumerates the evidence sources. Combined with full schema coverage and clear annotations, an agent has enough information to select and 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description restates that the target can be an endpoint URL, seller domain, or wallet address, but it does not add parameter-level semantics beyond what the schema provides; the baseline of 3 is appropriate.

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

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

The description states a specific decision task ('Should your agent pay this?') and a specific resource class (x402 / pay-per-call endpoint, seller, or wallet address). It also names the return verdicts and the checks performed, so an agent can distinguish it from sibling tools like vendor_trust_profile or x402_market_report without opening the schema.

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

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

It gives a clear trigger: 'Run before paying an x402 / pay-per-call endpoint, an unfamiliar seller or a wallet address.' That is strong contextual guidance, but it does not state when not to use the tool or name an alternative sibling for overlapping trust/readiness checks.

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 non-obvious behavior: pages are checked roughly once a day, querying a new company starts tracking it, and history only accrues from that day forward. That side effect and the data-latency caveat are exactly what an agent needs before deciding to call 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?

Content is front-loaded: the capability and returned fields come before the tracking caveat. The opening rhetorical question ('Did they raise prices or change their terms?') is padding, and the three-part return list could be tightened.

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 — enumerating price, plan/trial, subprocessor and text deltas plus current prices — while also covering the tracking caveat. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, so both domain and since_days are already documented with format, default and bounds. The description adds no syntax or scoping detail beyond the schema, so the baseline 3 applies.

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

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

States a concrete resource (pricing, terms of service, privacy policy, subprocessor page changes) and what is returned (change history plus current prices), which cleanly separates it from sibling company_profile, a static snapshot tool. An agent can identify the tool's job 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 scenario-based context ('competitor monitoring, vendor renewals and compliance') and a key precondition implied by the tracking model. It never names a sibling alternative (e.g., company_profile or check_before_paying) or states when NOT to use it, so routing is inferred 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes beyond that by naming the external sources (own website, Wikidata, SEC EDGAR, RDAP, DNS) — signalling third-party lookups, variable coverage and latency — and by noting prices are returned 'with the date seen,' which discloses data-freshness semantics.

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

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

The key phrase 'Company profile from a domain' is front-loaded, followed by an efficient comma-separated inventory of returned fields and a source list. It is one long run-on sentence, but every clause enumerates concrete output and none 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 must carry the return contract, and it does so thoroughly by listing every returned field plus the underlying sources. Gaps are minor: no mention of caching, rate limits, or behavior when a domain is unknown or the company is not in Wikidata/EDGAR.

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

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

There is only one parameter and schema description coverage is 100%, so the schema already documents the domain format with an example. The description repeats the 'from a domain' input but adds no syntax or normalization detail beyond the schema, 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 states a specific resource (company profile) and input (a domain), then enumerates the exact contents returned — summary, HQ, industry, SEC listing data, key pages, tech stack, domain age, AI-readiness. This scope makes it clearly distinguishable from siblings like company_changes, vendor_trust_profile, or email_domain_check 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?

Usage is implied by the field list and the named data sources, so an agent can infer 'call this to profile a company from its domain.' However, there is no explicit when-to-use or when-not guidance, and no routing to alternatives such as vendor_trust_profile for trust assessment or email_domain_check for mail-only lookups.

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 goes much further: it lists the exact verdict values, the full set of signals returned (MX/null MX, SPF, DMARC, RDAP age, website load), and critically discloses a limitation (no mail-server contact, so mailbox existence cannot be confirmed). This is exactly the behavioral context annotations cannot carry.

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

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

The purpose is front-loaded as a question, followed by use cases, return signals, and the key limitation. It is dense but every sentence carries information, with no boilerplate 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 fully covers return values (verdict plus each evaluated signal) and the important negative capability. An agent has everything needed to call it and interpret results 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?

There is a single parameter with 100% schema coverage, and the schema already documents that it accepts an email or a bare domain. The description restates this duality but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description opens with a specific, unambiguous purpose (determining whether an email address or domain is real/legitimate) and enumerates what it evaluates. It is easily distinguished from siblings like check_ai_crawler_access, package_check, or vendor_trust_profile.

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 names four concrete contexts (lead research, signup/fraud screening, outreach list cleaning, vendor checks), which clearly signals when to use it. However, it never names an alternative tool or an explicit when-not-to-use condition, 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 only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the ranking signal (calls per paying wallet over 30 days), that top candidates are probed live for payment status and price, the per-result fields and flags, and that it never pays. This is unusually rich 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?

Front-loaded with the core promise, then methodology, then output shape. Dense but nearly every clause carries information. It runs long as a single paragraph, and a couple of list-like enumerations would read more cleanly.

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

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

Despite having no output schema, the description enumerates the returned fields (URL, method, price, network, rationale, flags) and the flag semantics, plus the live-check and ranking behavior. An agent has everything needed to call it 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 schema already documents all four parameters. The description adds meaning beyond the schema by clarifying what check_live actually verifies (still asking for payment, at the listed price) and by tying limit to the 'top 1-5' framing and price comparisons to max_price_usd.

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

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

States a specific verb and resource: retrieve the top 1-5 pay-per-call x402 APIs matching a described task, drawn from an hourly index of ~38,000 endpoints. The scope is precise and unambiguous. It does not, however, distinguish itself from siblings like check_before_paying or x402_market_report, which an agent may find overlapping.

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 phrasing (describe a need, get ranked APIs), and the ranking rationale gives implicit context for when results are trustworthy. But there is no explicit when-to-use vs when-not guidance and no named alternative tool for adjacent tasks such as vetting a single endpoint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'No network access', usefully signaling a pure local generation. It also clarifies the blocking semantics of the 'balanced' policy, though it doesn't describe the output artifact beyond its name.

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

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

A single front-loaded paragraph that opens with the purpose, then the policy definitions, then the optional surface. Dense but every clause maps to a real capability; 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 7 parameters, a nested overrides object, and no output schema, the description should do more: it omits the meaning of site_url and never describes what is returned (a robots.txt string, recommendations, etc.). The core configuration surface is covered, but gaps remain for a tool of this complexity.

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 very low (14%), so the description must carry the load, and it does explain the policy values and enumerates the optional features (per-bot overrides, allowed/blocked paths, sitemap, crawl delay) that map to the other parameters. It leaves site_url undefined, keeping it short of full compensation.

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 (generate) and resource (robots.txt rules for AI crawlers) scoped to a named input (policy). The resource is clearly distinct from the sibling generate_llms_txt, so an agent can tell what it produces 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 defines what each policy value means (open/balanced/block), which implies the selection context, but it never states when to choose this tool over alternatives like generate_llms_txt or check_ai_crawler_access, nor any prerequisites. Usage is implied rather than 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=true and openWorldHint=true, and the description usefully adds the beyond-annotation behavior: missing inputs are backfilled from the homepage and sitemap.xml (explaining the open-world access), and the response is file text plus improvement notes. It stops short of noting fetch limits, failures, or cost.

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

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

Three tight sentences with no filler: what it makes, how inputs are resolved, and what comes back. The most decision-relevant information (the artifact) is front-loaded.

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

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

For a read-only generator with no output schema, the description covers the return payload and the input-resolution behavior, which is the critical missing piece. The remaining gap is minor: max_pages and site_name semantics, and any distinction from the robots.txt 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 60% (pages, summary, site_url documented; site_name and max_pages bare), so the baseline is 3. The description reinforces the fallback semantics for pages/summary and names site_name, but it never explains max_pages or its 5–60 bounds, leaving one parameter undocumented in both places.

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 artifact ('Generate an llms.txt file') plus the governing format (llmstxt.org) and the target ('a public website'), so the agent knows exactly what is produced. It does not, however, distinguish itself from the sibling generate_ai_robots_txt, which is the nearest-neighbor alternative.

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

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

Scoping is implied by 'for a public website' and the fallback rules tell the agent it can call with just site_url, but there is no explicit when-to-use/when-not guidance and no routing to or away from generate_ai_robots_txt.

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 genuinely useful behavior beyond that: the return shape (clean Markdown with title, URL, dates, tags front matter) — important since there is no output schema.

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

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

Two tight sentences, front-loaded with purpose and then input forms. Nothing redundant or 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 simple read-only fetch with no output schema, naming the return format is the key missing piece and it is present. The only real gap is max_chars truncation semantics, which an agent may need to interpret results 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 50%: slug is documented in the schema, and the description's slug/URL note largely repeats it. The undocumented max_chars parameter (default, min/max) is never mentioned — no truncation behavior is described — so the description does not compensate for the coverage gap.

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

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

Specific verb+resource ('Return one Stormap guide'), with scope ('one') that distinguishes it from the sibling search_guides. The output format is named, so an agent knows exactly what this tool produces.

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

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

It states the accepted input forms (slug or stormap.ai post URL), which implies it is for fetching a known single guide, but it never says when to use this versus search_guides or read_url. No exclusion or prerequisite guidance is given.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond that — the four verdict outputs (ok_to_install, caution, dont_install, does_not_exist) and the upstream sources queried (OSV.dev, deps.dev, npm registry, PyPI). It does not mention rate limits, network failure modes, or latency, which is the remaining gap for a tool that fans out to four external services.

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 trigger (before installing), then a dense checklist, then the verdict vocabulary and data sources. Every clause carries information and nothing is repeated from the schema. The long mid-sentence enumeration is heavy but readable and earns its length.

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, and the description compensates by disclosing the return vocabulary (the four verdicts plus reasons) and the coverage of each check, so an agent knows what it will get back and how to branch on it. Combined with the annotated safety profile and full schema coverage, nothing needed to invoke or interpret this tool 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 name formats, the optional version default, and the npm/pypi enum are already fully documented in the schema — baseline 3. The description adds a small amount of meaning by explaining why a version matters ('which known vulnerabilities affect this version, with the fixed version'), but it does not elaborate on parameter interactions or defaults beyond the schema.

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

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

The description names a specific verb+resource (check an npm/PyPI package before installing) and enumerates exactly what is checked: existence, malicious reports, known CVEs with fixed versions, deprecation/yank status, age, install scripts, download counts, typosquatting. It is unmistakable against siblings such as vendor_trust_profile or check_before_paying, which concern vendors and payments rather than package artifacts.

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

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

The opening clause gives an explicit trigger condition: 'Before installing an npm or PyPI package'. It also supplies the motivating context (AI-suggested names are sometimes fabricated, attackers register them). It stops short of naming when not to use it or an alternative tool, but no sibling overlaps this domain, so the guidance is operationally sufficient.

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 what gets stripped (navigation, footers, scripts, cookie banners), what metadata is returned, the no-JavaScript limitation, and robots.txt compliance. These are exactly the behavioral traits an agent needs to predict output quality and failure modes.

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

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

Front-loaded with the core action and output format, and the trailing sentence carries the two key operational caveats. The metadata enumeration is slightly list-heavy but every item is informative, so waste is minimal.

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

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

With no output schema, the description carries the return-value burden and does so fully: it names the Markdown payload, the stripped elements and the metadata fields. Combined with the stated limitations, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so both 'url' and 'max_chars' are already documented with types, bounds and defaults. The description adds no syntax, format or truncation detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('fetch a public page and return its main content as clean, LLM-ready Markdown') and immediately names the transformation and scope. No sibling tool competes for this job, and the title plus first clause make the function 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?

Gives clear context for use and an implicit exclusion: 'Reads server-rendered HTML (no JavaScript execution)' tells the agent this will fail on JS-rendered SPAs, and 'respects robots.txt' signals blocked pages. It does not name an alternative tool or state explicitly when not to use it, so it falls short of a 5.

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

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

Annotations already establish the safety profile (readOnlyHint=true) and closed scope (openWorldHint=false), and the description reinforces that scope by naming the guide corpus. It also discloses the return shape (titles, URLs, Markdown URLs, short descriptions), which is genuinely valuable because no output schema exists. It omits ranking/pagination behavior for the limit parameter.

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

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

Two sentences, front-loaded with the verb and corpus before the return-value clause; no filler. The long parenthetical topic list is the only bulk, and it does earn its place as query-vocabulary guidance for an LLM searcher.

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 three-parameter search tool with no output schema and no nested objects, the definition covers what is searched and what comes back. It stops short of explaining result ordering or how `limit` interacts with the `category` filter, which are the remaining 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 67%: `query` and `category` carry good examples, while `limit` has only bounds/default. The description's topic list implicitly documents the query vocabulary but adds no parameter-level detail beyond what the schema already says, so the baseline of 3 applies.

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

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

States a specific verb ("Search") and resource ("Stormap's practical guides") and enumerates the topical coverage, so an agent immediately knows what corpus is being searched. It does not distinguish itself from the sibling `get_guide`, which is the obvious alternative for retrieving a known guide.

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 statement of when not to use it, and no mention of the sibling `get_guide` (which presumably fetches a specific guide by id/URL). An agent must infer that this is the discovery path and `get_guide` the retrieval path purely from the names.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), but the description adds genuinely useful behavior: the feed is Nasdaq-sourced and refreshed every minute, which markets are covered, and the possible status values (halted, resuming_soon, resumed). It stops short of noting rate limits or staleness caveats, so 4 rather than 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 resource and scope, then return fields, then filtering. Information-dense with little waste, though the first sentence is long and clause-heavy rather than tightly structured.

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

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

With no output schema, the description enumerates the return fields (symbol, market, plain-English reason, halt time, resume time, status) and discloses freshness (refreshed every minute) and source. Nothing an agent needs to invoke this read-only, single-param tool correctly is missing.

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

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

Schema coverage is 100% and the single optional parameter is fully documented in the schema itself. The description's 'filter by one or more tickers, or omit for all' merely restates that, adding no format or syntax detail beyond what is already structured.

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 (US stock trading halts) with explicit scope (right now and earlier today, Nasdaq/NYSE/NYSE American), names the data source (Nasdaq halt feed), and enumerates the returned fields. An agent can distinguish it from siblings like why_is_it_moving 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 says how to filter (by tickers, or omit for all) but never states when this tool is the right choice versus alternatives such as why_is_it_moving, nor any exclusions. Usage is implied by the real-time halt framing 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 declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond them: the data is scraped from the vendor's own public site, AI-training findings come with an 'exact quote and page,' and crucially certifications are 'vendor claims, not verified audits' — an important reliability caveat. It does not mention rate limits, caching, or failure modes when a domain lacks a trust page.

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 purpose and the two headline questions before the long enumeration of returned fields. The middle sentence is dense but each item (certifications, subprocessors, DPA, SSO/SAML, security.txt, trust center links, transparency score) is distinct information, not filler; only the certification-suite listing is arguably over-enumerated.

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 describe returns, and it does so thoroughly — fields, score, and supporting links — plus the caveat that certifications are unverified claims. For a one-parameter, read-only lookup tool this is complete enough to call 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?

Only one parameter with 100% schema description coverage, so the schema already carries the semantics. The description restates the input implicitly ('given a domain') without adding format or edge-case guidance beyond the schema's own example. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'a first-pass security and privacy profile of a software vendor from its own public website, given a domain.' It also names the concrete questions it answers (SOC 2, AI training on customer data), which separates it cleanly from siblings like company_profile, email_domain_check, and package_check.

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

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

Explicitly routes usage: 'Use for vendor risk assessments, procurement and security questionnaires.' That is clear context for adoption, but there is no statement of when NOT to use it or which sibling to prefer for adjacent needs (e.g. company_profile for general firm data).

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

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

With annotations already declaring readOnlyHint and openWorldHint, the description still adds substantial behavioral context: the explicit answer-status values (filing_found, news_halt_no_filing_yet, unexplained_by_primary_sources) and the coverage block let an agent distinguish 'nothing filed' from 'a source failed'. This is exactly the kind of operational transparency that 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?

The value proposition and scope are front-loaded in the first sentence, followed by the ranked output detail. It is dense and long, but nearly every clause carries specific, non-redundant information; a small amount of the enumeration could be tightened.

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 carry the full burden of describing return values — and it does, covering ranking rationale, per-item fields (time, filing link, rank reason), filing-burst guidance, answer status, and coverage metadata. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so both parameters (ticker, hours) are already documented with examples and bounds. The description only adds that the window is 'adjustable' and reiterates the 48-hour default, adding little beyond the schema — the baseline 3 is appropriate.

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

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

The description states a specific verb and resource — it returns the likely catalysts behind a US stock move, sourced from primary filings — and enumerates exactly what that includes (8-K events, Exhibit 99.1 headlines, offerings, Form 4 insider trades, 13D/13G stakes, halt status). This is far more precise than the bare title and lets an agent distinguish it from sibling tools like trading_halts or company_changes.

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 scopes usage clearly ('For a US stock ticker', last 48 hours adjustable) and gives an exclusion ('Facts only: no price data and no buy/sell opinions'), which tells the agent when not to reach for it. However, it never names an alternative sibling (e.g., trading_halts) or states explicitly when another tool should be preferred over this one.

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), and the description adds meaningful context beyond them: the data source (Coinbase's x402 marketplace), the refresh cadence (hourly index), the lookback window (last 30 days), and the measurement basis (prices "paying wallets actually accept", distinct paying wallets rather than raw calls). It does not mention rate limits or latency, so it is not exhaustive.

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

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

Three sentences, all front-loaded: the resource and source first, then the report contents, then the use case. The enumeration of report outputs is dense but each item earns its place by telling the agent what it will get back.

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 return values, and it does so thoroughly (price stats, distribution, top sellers, new listings, concentration metric). Combined with annotations covering the read-only safety profile and full schema documentation of the three parameters, 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%, with all three parameters (limit, query, category) documented in the schema itself, so the baseline is 3. The description restates the category/query distinction and the 30-day window but adds no format or edge-case detail (e.g., query vs. category precedence, what happens when both are supplied).

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

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

The description names a specific resource and scope: an hourly index of Coinbase's x402 marketplace (~38,000 pay-per-call endpoints) reporting prices and sellers. It enumerates exactly what the report contains (median/middle/top-10% prices, distribution, top sellers by distinct paying wallets, new listings, concentration), which makes it clearly distinguishable from per-vendor siblings like find_best_api or vendor_trust_profile.

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?

"Use it to price your own x402 endpoint, or to pick which paid tool to call" gives explicit when-to-use context. However, no when-not condition or named alternative is given, 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.