Rhea

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, etc. The description adds valuable context: the scoring range (0-100), per-model return structure (score, confidence, signals, raw_response), and the fact that Anthropic calls use the user's own API key and incur direct costs. No contradictions 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?

The description is three sentences, front-loaded with the primary purpose, then details on defaults and usage. Every sentence provides actionable 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?

Despite lacking an output schema, the description explains return values: 'per-model {score, confidence, signals, raw_response} + a combined view.' All four parameters are adequately described, and usage guidelines are clear. For a moderately complex tool, this is complete.

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

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

Input schema already describes all parameters (100% coverage). The description adds context beyond schema: it names the default model ('Workers AI Llama-3.3-70b (free)') and explains _apiKey as 'BYO key — you pay Anthropic directly.' It also describes the return structure, which is not 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?

The description clearly states the tool probes LLMs for knowledge about a business/brand/product/topic and scores visibility 0-100 per model. It specifies the default model (Workers AI Llama-3.3-70b) and the optional Anthropic integration. This distinguishes it from siblings like scan_competitor_ai_presence, which likely focuses on competitors.

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

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

The description explicitly states use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also notes the cost implications of using Anthropic (BYO key). However, it does not explicitly state when not to use this tool or provide alternatives.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description adds valuable behavioral context: auto-routing, automatic argument filling, stable pipeworx:// citation URIs, and live-news routing. There is no contradiction with 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 front-loaded with the key 'prefer over web search' directive and remains dense with useful routing and escalation guidance. The long category list and several trigger examples could be slightly trimmed, but no sentence is pure 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 tool with no output schema, the description clearly explains what the caller receives—a structured answer with stable pipeworx:// citation URIs—and when to escalate to alternatives. It gives enough context for an agent 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?

The schema already has 100% description coverage for all six parameters, which are aliases for the same natural-language question field. The description adds examples but does not meaningfully expand parameter semantics 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?

The description states a specific behavior: routing the question to one of 5,798 tools across 1,517 verified sources, filling arguments, and returning a cited structured answer. It also distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research, so an agent can tell them apart.

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 guidance is explicit: prefer over web search for current/historical factual data, use when the user asks 'what is', 'look up', 'find', etc., and start here for most questions. It also names alternatives: ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part questions.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable context beyond that: candidate routing improvements are 'enabled live whenever one is under test', no candidate is currently active (retired 2026-07-26), and 'this IS a full working router, just the experimental edge'. This explains current state without contradicting annotations.

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

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

The description is four sentences that flow efficiently: purpose, current status, usage instruction, and clarifying caveat. Each sentence contributes distinct information with no redundancy, and the beta nature 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 beta mirror tool, the description is complete: it clarifies it is a full router, how it differs from stable, and why to use it. It references 'same response shape' as ask_pipeworx instead of detailing the response, which is reasonable given the sibling relationship, but a standalone response format description would improve completeness since there is no output schema.

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

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

The input schema has 100% coverage, with all 6 parameters described as aliases for 'question'. The description only says 'same arguments' as ask_pipeworx, adding no semantic detail beyond the schema. Since the schema already documents everything, 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 it is a 'Beta version of ask_pipeworx: identical universal router' with the same tools, arguments, and response shape. It clearly distinguishes itself from the stable ask_pipeworx by focusing on experimental routing, so an agent can tell it apart from siblings like ask_pipeworx and ask_pipeworx_grounded.

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

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

It explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router to decide merges. This gives clear context, though it does not explicitly state when NOT to use it (e.g., production stability preference), leaving that slightly implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond that: the extra LLM call cost, the guarantee to extract only from tool results, the structured success payload, and the full set of refusal reasons. This is a strong disclosure of what the agent should expect.

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 every sentence earns its place: it explains mode, routing, extraction guarantee, return shape, refusal reasons, use cases, and cost tradeoff. Information is front-loaded with the key differentiator, and the structure makes it easy to scan. No filler or redundancy.

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

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

For a tool with no output schema, the description fully covers what the agent needs: return structure, refusal reasons, success evidence, cost difference, and selection criteria versus the sibling tool. It covers both normal and failure paths. Nothing important is missing for correct invocation and interpretation.

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 the question field and all aliases fully documented in the input schema. The description does not add meaningful parameter-level semantics because the user-provided question is straightforward; the internal tool routing arguments are about behavior, not user parameters. Baseline 3 applies since the schema fully carries parameter meaning.

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 combination: a grounded, hallucination-resistant answer mode that pulls data via the same routing as ask_pipeworx and extracts answers only from tool results. It distinguishes itself from ask_pipeworx by emphasizing evidence-backed answers and explicit refusals. An agent can immediately understand what this tool does and how it differs from its sibling.

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

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

Provides explicit when-to-use guidance: use when answers will be quoted, cited, or acted on, especially for financial, legal, medical, or public-statement contexts. It also names the alternative, ask_pipeworx, and says to prefer that for casual lookups because of the extra LLM call cost. This is clear routing guidance with no ambiguity.

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?

Given rich annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds substantial context: resolution process, fan-out examples, safety mechanisms (low-confidence match blocking, closed market handling, wide-spread warnings), resolver contract details (market_match_confidence, alternatives, suggestions), parent event extraction, and resolution-rule risk. No contradictions 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?

The description is long but well-structured with sections (CAPS headings) and examples. It front-loads the core purpose and usage. While every sentence adds value, the length could be reduced by grouping related details. Overall, it earns its length for a complex tool.

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

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

Despite lacking an output schema, the description provides comprehensive details on response shapes, resolver contract, parent event extraction, news fields, and edge cases (low confidence, closed markets, wide spreads, cancellation rules). Parameter count is low, but the tool's complexity is fully covered.

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 reiterates the market input formats (slug, URL, question text) but does not add new semantics beyond what the schema already provides for each parameter. The depth and include_raw parameters are adequately documented in the schema, and the description's examples add no further detail.

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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call'. It specifies input types (slug, URL, question text) and output components (evidence packet, market-vs-model comparison). The verb 'research' combined with the resource 'Polymarket bet' distinguishes it from sibling tools like ask_pipeworx or polymarket_edges.

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?

Explicit use cases are listed: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. Examples of fan-out by category are provided. However, it does not explicitly state when NOT to use this tool versus alternatives (e.g., when only a quick price check is needed), leaving the agent to infer.

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 annotations (read-only, open-world, idempotent), it reveals off-calendar fiscal year handling, sorted results by primary metric, citation URIs, and specific data fields per entity type. No contradictions 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?

Well-structured with trigger phrases upfront, followed by details. Slightly verbose but each sentence adds value. Could trim some redundancy, but overall efficient.

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

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

No output schema, but description explains return includes paired data and citation URIs, and sorting by primary metric. Covers entity types, data sources, and usage scenarios adequately for a complex comparison tool.

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

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

Schema coverage is 100%. Description adds meaning by explaining enum options ('company' vs 'drug') with their data sources, and clarifies array values require tickers/CIKs for companies and drug names for drugs, including examples.

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 it performs side-by-side comparisons of 2-5 companies or drugs, with trigger phrases like 'compare X and Y' and explicit data sources (SEC EDGAR/XBRL for companies, FAERS for drugs). It distinguishes itself from entity_profile by emphasizing parallel vs sequential lookups.

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 advises 'ALWAYS PREFER over sequential single-pack lookups' and provides example queries. It lacks explicit when-not guidelines but implies alternatives through sibling differentiation.

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 discloses significant behavioral detail beyond annotations: account/plan requirements, parallel decomposition, findings packet structure with gaps[], citation_uri and hop fields, contradiction scanning, semantic excerpting, and latency expectations. It also confirms non-mutating behavior consistent with readOnlyHint and destructiveHint, with no contradictions.

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 information-dense and front-loaded with critical access constraints and the primary alternative, with nearly every sentence adding value. However, the heavy use of nested parentheticals and run-on clauses makes it harder to scan quickly; it could be better organized even while retaining its detail.

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, high-level research tool with no output schema, the description is remarkably complete: it explains return shape, evidence provenance, failure representation via gaps[], contradictions, citation fetchability, large-record handling, latency, and depth-specific behavior. An agent has enough context to invoke 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 schema already documents both parameters well. The description adds meaningful extra semantics, including the paid requirement for 'thorough', the second-hop behavior of 'standard', lead-chasing in 'thorough', and latency differences, which helps an agent choose parameter values more effectively.

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 defines the tool's function: grounded, multi-source research over Pipeworx's structured data sources, with decomposition and parallel routing. It explicitly contrasts itself with 'open-web search' and distinguishes itself from siblings like ask_pipeworx, making its purpose 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?

Provides explicit guidance on when to use the tool ('Best for broad/multi-part questions over structured data') and when not to ('For a single lookup use ask_pipeworx instead'). It also names an alternative for unsigned-in users and explains depth-tier requirements, giving an agent clear decision criteria.

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 annotations (readOnlyHint, idempotentHint, etc.), description adds that it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)' and that each result is 'ready to call directly'. 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?

Description is a single focused paragraph that front-loads purpose, provides examples, details return format, and ends with usage advice. Every sentence adds value, though minor redundancy (aliases) could be trimmed.

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

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

For a tool with no output schema, the description adequately explains what is returned (top-N tools with schemas and examples). Covers safety via annotations and usage context. Could mention more about ordering or filtering but sufficient.

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 all parameters described. Description adds context about aliases (task, q, description, search) and provides example queries, adding value beyond schema alone.

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 it finds tools by describing the data or task, lists specific domains (SEC filings, financials, etc.), and distinguishes from siblings by positioning it as the first call to discover the option set, not just one answer.

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

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

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for:' and 'Call this FIRST when you have many tools available and want to see the option set'. Provides strong positive guidance but lacks explicit exclusions or alternatives.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses fan-out behavior across EDGAR/XBRL/patents/contracts/FDA/H-1B/news/GLEIF, the sources_used/sources_failed semantics, empty-section meaning, and resolved:false behavior for private companies. 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?

The description is dense and front-loaded with trigger phrases and the core purpose, and every clause carries information about inputs, sources, or output behavior. It is long, but the complexity of the tool justifies the length; light formatting would make it easier to scan.

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 return-value semantics, and it does: it lists returned fields, source success/failure reporting, URIs, and edge-case behavior. An agent has enough context to call entity_profile correctly and interpret its response.

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

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

The schema already covers both parameters at 100%, so the baseline is 3. The description adds practical invocation examples (AAPL, 0000320193, Moderna), affirms that type values are interchangeable, and clarifies that names resolve through SEC EDGAR, adding real value 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 concrete user phrasings and then states the exact purpose: a full cross-source profile of a US public company in one parallel call. It explicitly differentiates itself from chaining single-pack SEC/XBRL/news lookups, so an agent can recognize when this is the intended 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?

It gives an explicit ALWAYS PREFER rule for holistic-view requests and explains accepted inputs (ticker, zero-padded CIK, or company name). It also sets expectations for edge cases like private companies, which is enough guidance for selecting and invoking the tool.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds context about the nature of deletion and the rationale (clearing sensitive data), which is valuable beyond the annotations.

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

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

Two concise sentences, no wasted words, purpose is front-loaded. Every sentence earns its place.

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

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

For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and behavioral context, including reference 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 coverage is 100% and the description does not add extra meaning beyond the schema's 'Memory key to delete' for the only parameter. 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 verb ('Delete') and the resource ('previously stored memory by key'). It distinguishes from siblings by explicitly mentioning 'remember' and 'recall' as companion 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 provides explicit use cases: when context is stale, task done, or clearing sensitive data. It also pairs with siblings, giving clear guidance on when to use this tool vs alternatives.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) align with description. Description adds process details: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' This provides behavioral context beyond annotations, though still concise.

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 concise with 3 sentences, front-loading the purpose, then process, then use cases. No redundant information, each sentence serves a distinct 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?

Given the tool's simplicity (2 params, no output schema, rich annotations), the description covers purpose, process, output format, and use cases. Missing error handling or invalid URL behavior, but overall sufficient for effective use.

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 clear parameter descriptions for 'url' and 'max_links'. Description does not add new semantic information beyond what the schema provides, so baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: 'Generate a production-ready llms.txt file for any URL so AI crawlers... can index the site cleanly.' It specifies the verb (generate), resource (llms.txt file), and target URL, distinguishing it from sibling tools like scan_competitor_ai_presence.

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 explicit use cases: getting a client's site indexed, drafting for own project, or auditing competitor AI crawl. While it doesn't explicitly state when not to use, the examples are sufficient context. No alternative siblings directly compete, so guidance is clear.

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

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

Annotations already indicate safe read-only, idempotent behavior. Description adds valuable return content details (equation, cross-references) and notes it is 'Keyless' (no auth). No contradictions.

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 concise sentences, front-loaded with action and resource, no wasted words. Efficient and clear.

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

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

No output schema, but description lists key return fields (equation, EC, ChEBI, etc.), compensating well. Could mention pagination or error hints, but sufficient for a single-param fetch.

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 covers 100% of parameter description; description repeats id examples without adding new semantic details. 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?

Description clearly states the action ('Fetch a single Rhea reaction') and resource ('by its Rhea id'), with example formats. Distinguishes from sibling tools like search_reactions.

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

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

Implied use for single reaction lookup, but no explicit when-not-to-use or alternative recommendations (e.g., for searches). Adequate for a simple fetch tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds return field details and default behavior (active only), which is useful but not critical beyond annotations.

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

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

Two sentences with no wasted words: first sentence states purpose and output, second sentence gives usage guidance. Front-loaded and 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?

The tool is simple with one optional parameter and no output schema, but the description explicitly lists return fields, making it fully comprehensive for an agent to use.

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 description does not add extra parameter meaning. The baseline of 3 is appropriate as the schema already handles parameter documentation.

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

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

The description clearly states 'List the caller's active subscriptions' with a specific verb and resource, and distinguishes from siblings like 'subscribe' and 'unsubscribe' by focusing on listing.

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

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

The description explicitly says when to use: 'to review what you're monitoring before adding more or to find an id to cancel.' It provides clear context but does not name alternatives.

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

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

The description discloses several behavioral traits not captured by annotations: it can return a claim_token when no account is attached, supports a follow-up mode via that token, is rate-limited to 5 per identifier per day, and does not count against tool-call quota. These operational details are valuable and go well beyond the all-false annotation hints.

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 long but dense, and most sentences earn their place by providing actionable details (usage cases, exclusions, claim_token mechanics, rate limits). It is front-loaded with the core purpose and use cases. However, a few sentences ('The team reads digests daily and signal directly affects roadmap.') are more motivational than essential for tool invocation, preventing a perfect score.

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 (multiple feedback types, optional structured context, follow-up mode via claim_token, rate limits, and no output schema), the description covers all necessary operational aspects: when to use, what to include, how to follow up, and constraints. It is fully self-sufficient for the agent to invoke the tool correctly in various scenarios.

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 schema already documents all parameters (100% coverage), so the baseline is 3. The description adds meaningful guidance beyond the schema: it explains the claim_token follow-up flow, gives content guidance ('don't paste the end-user's prompt'), and expands on the type enum through examples. This raises the score to 4.

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?

Purpose is explicitly stated with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes from siblings by enumerating concrete use cases (bug, feature/data_gap, praise) and explicitly excluding tools from other MCP servers.

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 explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a clear exclusion rule for tools from other MCP servers and offers a fallback check ('Not sure? Pipeworx tool names are the ones this connection lists').

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 indicate read-only, idempotent, non-destructive behavior. The description adds substantial value by disclosing that data is self-aggregating from CF analytics-engine, no PII, only (pack, tool, count), and caching periods (5min-1h depending on window). 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?

The description is concise (three sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, use cases, behavioral notes. No wasted words or redundancy.

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

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

For a tool with one optional parameter, no output schema, and clear annotations, the description covers all essential aspects: what it returns, time windows, use cases, data source, caching, and privacy. No gaps remain.

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 parameter 'window' is fully covered by the schema (enum values, description). The description adds contextual nuance ('shorter windows surface what's hot right now; longer windows show steady-state demand'), going beyond the schema to aid selection.

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 starts with a clear, specific verb phrase ('What other AI agents are calling on Pipeworx right now') and explicitly identifies the return values (top tools, top packs, total call volume). It distinguishes itself from siblings by focusing on aggregated trending data rather than individual queries or entity lookups.

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 enumerates three concrete use cases (discovering hot data sources, confirming canonical tools, seeing alignment with trend). However, it does not explicitly state when not to use this tool or provide alternatives, leaving room for improvement.

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

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

The description adds extensive behavioral context beyond annotations, including the top ~200 market scan scope, semantic anchor (0.30 Jaccard), partition filter, and fill check against live CLOB depth, including when not to trade. Annotations already indicate read-only and open-world, no contradiction.

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

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

The description is detailed but front-loaded with the main purpose. Each sentence earns its place, though the length could be slightly trimmed without losing clarity. The structure is logical and aids understanding.

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 lacking an output schema, the description fully explains the return fields (opportunities[] with gap_pp, suggested_trade, reasoning, monotonicity context, and event-mode partition_check). It also covers fill-check, trade recommendations, and internal filters, making it complete for a complex 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?

While the schema covers 100% of parameters with descriptions, the description enriches them by explaining the full behavior for each mode (e.g., event walks child markets, topic searches related events) and the output structure, exceeding baseline expectations.

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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks, specifying three modes (no-args, event, topic). It distinguishes from sibling tools like polymarket_edges by focusing on arbitrage logic.

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 explicit guidance on when to use each mode (no-args for trending scan, event for a specific market, topic for cross-event) and mentions an alternative tool (polymarket_fill_risk) for custom sizing, helping the agent choose correctly.

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 richly discloses behavioral traits beyond annotations: caching behavior, response structure with segments and diagnostics, Fed bets exclusion rationale, and detailed model explanations. No contradictions 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?

The description is well-structured with clear sections and front-loaded purpose, but it is verbose with extensive technical details on model families. Some details could be streamlined, but overall efficient for the complexity.

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 9 parameters, no output schema, and nested response objects, the description comprehensively covers response structure, diagnostics, caching, and special cases (Fed bets). It leaves no significant gaps for an agent to understand usage and output.

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

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

With 100% schema coverage, the description adds significant value by explaining the purpose and effect of each knob in context, such as min_liquidity dropping thin-book opportunities and min_partition_leg_kelly filtering thin partitions.

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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, with a specific use case 'what should I bet on today'. It distinguishes itself from sibling tools by focusing on discovering opportunities across many markets without paging.

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 clear context for when to use the tool (discovering betting opportunities) and explains the tradeable-edge knobs. However, it does not explicitly exclude alternatives or contrast with sibling tools like polymarket_arbitrage.

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 indicate readOnlyHint, idempotentHint, and non-destructive. The description adds significant value by explaining the response structure (tracked[], expired[], snapshot_dates[]), the meaning of decay_pp_per_day (negative = SELL YES), and limitations (60-day TTL, no intraday). 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?

The description is well front-loaded with the core purpose and includes necessary technical details. It is slightly dense but every sentence adds value. Could benefit from slight restructuring for readability.

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

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

Despite lacking an output schema, the description thoroughly explains all response fields (tracked, expired, snapshot_dates) and their semantics. It also covers limitations and edge cases (e.g., gaps in snapshots). Complete for a read-only telemetry tool.

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

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

Schema coverage is 100% with parameter descriptions. The description adds extra context beyond the schema, such as default values (14 for days, '1wk' for window), bounds (max 30, clamp 2-30), and explanation of 'window' as snapshot family.

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 explicitly states 'Edge persistence and decay telemetry' and answers a specific question about edge longevity. It distinguishes itself from the sibling 'polymarket_edges' by focusing on historical tracking vs. current edges.

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 clear context on when to use this tool (e.g., evaluating whether a wide edge is fresh or old). Implicitly distinguishes from 'polymarket_edges', but lacks explicit 'when not to use' or alternative recommendations.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, etc., and the description confirms it is a non-destructive check. It adds operational details like 'walks the ladder', returns verdicts (clean|degraded|cannot_fill), and warns about forced directional risk, complementing the annotations without 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 fairly long but well-structured with clear sections for SINGLE-MARKET and BASKET modes, and lists return fields. Every sentence is informative, though some verbosity could be trimmed. Overall, it is concise enough for its complexity.

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

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

Given the complexity of two modes and no output schema, the description does a good job explaining return values and usage scenarios. However, it lacks detailed explanation of verdict meanings (e.g., clean vs degraded) and some return fields. Still, it provides enough for an AI agent to use 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% with parameter descriptions, but the description adds significant context: explains how size_usd is interpreted differently in single-market vs basket, default behavior for side in basket mode (auto), and clamping range. This adds value 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 clearly states the tool performs a 'realizable-vs-theoretical edge check' against live order book depth, and explains both single-market and basket modes with explicit output fields. It distinguishes itself from sibling tools like polymarket_arbitrage by specifying it should be used before acting on arbitrage signals.

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

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

The description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', providing clear when-to-use and when-not-to-use guidance. It also warns about the danger of partial basket fills converting an arb into unhedged directional position.

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 idempotentHint already covering safety, the description adds rich behavioral context beyond annotations: fees are gross not net, matching is keyword/word-overlap based and never verified against a shared resolution source, unclassified legs are never paired, and temporal_alignment null means uncomputable rather than aligned. This is far more than the annotations alone provide.

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

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

The description is long, but it is organized with clear labels (TWO MODES, RESPONSE, SAFETY FIELDS, Codes) and nearly every sentence carries necessary operational detail. Front-loaded purpose and mode explanation earn it a high score, though its density and enumeration of many codes prevent a perfect 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?

Given there is no output schema, this description is remarkably complete: it enumerates response fields, compatibility codes and their meanings, per-entry flags, skipped-leg categories, fee treatment, and the meaning of temporal_alignment nulls. An agent has enough context to invoke the tool and interpret its output 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 the baseline is 3, but the description adds meaningful semantics: topic is a closed set of pre-mapped shortcuts, kalshi_event_ticker and polymarket_event_slug are explicit overrides, and both modes execute the identical token-overlap matcher. This helps an agent reason about parameter interactions beyond the schema's individual property descriptions.

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

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

The description opens with a specific verb and resource: it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It also explains the core premise—venues pricing the same outcome 2-25pp apart—which distinguishes this from sibling tools like polymarket_edges or polymarket_arbitrage without needing to read their schemas.

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

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

The description gives clear usage context: two modes, topic shortcuts versus explicit ticker/slug pairing, and the fact that both run the same matcher. It even warns that most pre-mapped topics may return compatibility warnings today. However, it never explicitly names alternatives or states when this tool should be preferred over related sibling tools like polymarket_arbitrage, so it stops short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's confirmation adds limited value. However, it does reveal the list-all-keys behavior when key is omitted, which is not in annotations. No contradiction.

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

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

The description is moderately sized with three sentences. It front-loads the core function and then provides examples and scope. It could be slightly more concise, but it's well-organized and each sentence adds value.

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 simplicity and the annotations covering safety, the description adequately covers the two usage modes (retrieve or list). No output schema exists, but the return behavior is inferred. It also mentions scope and pairing, making it reasonably complete.

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

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

Schema describes the 'key' parameter with full coverage. The description adds meaning by explaining the purpose of the key and the effect of omitting it (list all keys). This enhances understanding 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 clearly states the tool retrieves saved values via 'remember' or lists all keys when key is omitted. It uses specific verbs (retrieve/list) and identifies the resource (memory keys), effectively distinguishing it from siblings like 'remember' and 'forget'.

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 explains when to use the tool: to look up previously stored context without re-deriving it. It implies not to use for saving or deleting by mentioning pairing with 'remember' and 'forget'. It could explicitly state when not to use, but the context is clear.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) are already present. Description adds details about returned fields, mark_read behavior, and external endpoint, enriching behavioral context without 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?

Single, well-structured paragraph. Front-loaded with action and output, then details. No redundant sentences.

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

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

With 5 parameters, no output schema, the description explains output fields, filtering examples, polling behavior, and an alternative endpoint. Comprehensive for moderate 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 coverage is 100% with descriptions. The description adds contextual meaning for 'type' (example 'sec_8k') and 'mark_read' (flagging read). While 'limit' and 'unread_only' are not elaborated, schema descriptions suffice.

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 pulls fired events from a subscription feed, returning recent alerts. It distinguishes from siblings like 'recent_changes' by specifying the domain (alerts from subscriptions).

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 context for polling ('Polls work fine') and mentions an alternative external endpoint for scripts/dashboards. Does not explicitly exclude use cases or compare to other sibling tools, but the guidance is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and no destructive hint. The description adds operational details: fans out to SEC, GDELT/GNews, USPTO; explains GDELT→GNews fallback on 5xx/rate limits; notes USPTO soft-fail due to API sunset; and describes the output format with 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 description is a single, well-organized paragraph that front-loads the purpose with example queries, then covers behavior, parameter details, and output. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (multiple data sources, fallback, soft-fail) and no output schema, the description adequately explains the output structure (changes[] grouped by source, total_changes, citation URIs). However, it could be more detailed about the fields within each change item.

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

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

Schema coverage is 100%. The description adds value by explaining the 'since' parameter accepts ISO dates or relative shorthand with examples, and clarifies that 'value' can be a ticker or CIK. It also provides typical usage advice for 'since'. This goes beyond the 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?

The description begins with example queries like 'What's new with X' and clearly states it is a change feed for a company over a time window, using one parallel call. It explicitly distinguishes from the sibling 'entity_profile' 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?

The description provides explicit guidance on when to use this tool versus 'entity_profile' and gives a typical value for the 'since' parameter ('Use "30d" or "1m" for typical monitoring'). It also explains fallback behavior between GDELT and GNews.

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 provide idempotentHint and destructiveHint. The description adds important behavioral context: scoping by identifier, persistent vs session-based storage duration, and that it overwrites existing keys (implied by idempotent). Does not contradict 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?

Four sentences, no fluff. Front-loaded with purpose, followed by usage guidance, then behavioral details. Every sentence adds value.

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 key-value store tool with no output schema, the description covers purpose, use case, storage details, and links to companion tools (recall, forget). No gaps identified.

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 parameters are fully documented. The description adds a naming convention example but no additional semantics beyond what the schema provides. Baseline 3 applies.

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

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

The description uses a specific verb ('Save') and resource ('data'), provides concrete examples, and distinguishes from sibling tools (recall, forget). It clearly states what the tool does and in what context.

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

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

Explicitly says when to use ('when you discover something worth carrying forward') and mentions alternatives ('Pair with recall to retrieve later, forget to delete'). Provides clear guidance on when to invoke and when not.

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

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

Beyond the readOnly and idempotent annotations, the description reveals meaningful behavior: internal cascading lookups, graceful degradation when GLEIF/OpenFIGI are unavailable, and how non-equity instruments without tickers still resolve. This adds substantial context the annotations do not provide.

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

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

The description is front-loaded with purpose and usage, and every major clause carries useful information. However, it is a dense single paragraph with heavy nesting, so it is not as scannable as it could be; this prevents 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?

With no output schema, the description compensates by documenting returned identifiers for each type, accepted input forms, ownership data, citation URLs, and fallback behavior. An agent has enough to select inputs 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?

Even though the schema already describes both parameters, the tool description enriches them significantly: it explains accepted inputs for company (ticker, CIK, ISIN, name) and drug (brand or generic), and warns to pass only the entity name, not the full noun phrase. This goes well beyond the schema's 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?

The description opens with concrete user queries and states the tool's core job: resolve a user-spoken NAME to canonical/official identifiers other tools require. It names supported types and specific identifier outputs, making it clearly distinct from sibling tools like entity_profile or compare_entities.

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 explicit guidance: 'Use FIRST whenever you have a name but need an ID,' and provides illustrative query patterns. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral details: it probes each entity with 'ai_visibility_check', ranks by score, and returns a structure (score, confidence, signal density per entity). It also notes that the first entity is treated as the 'subject' for narrative. No contradictions 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?

The description is concise: 3 sentences covering purpose, method, use case, and output. It is front-loaded with the core action and efficiently uses every sentence without 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?

Despite lacking an output schema, the description clearly explains the return format: ranked list with score, confidence, signal density per entity. It covers all key aspects: parameters are well-described in schema, and the description adds processing logic (probing, ranking) and use case context. No obvious gaps for this tool's 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 100%, so baseline is 3. The description adds meaning beyond schema: 'First entry treated as the "subject" for narrative; rest are competitors.' This clarifies the ordering and semantic role of the 'entities' parameter, increasing its value.

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

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

The description clearly states the tool's purpose: 'Compare AI visibility across multiple entities side-by-side.' It specifies the verb (Compare), resource (AI visibility across entities), and outputs (ranked list with scores). It distinguishes from sibling tool 'ai_visibility_check' by emphasizing multi-entity comparison.

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 a clear usage context: 'Useful for competitive AI-marketing audits.' It implies when to use (comparing multiple entities) but does not explicitly mention when not to use or alternatives like 'compare_entities' or 'ai_visibility_check'. The comment about probing each entity with 'ai_visibility_check' hints at a simpler alternative for single entities.

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

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

Annotations already declare readOnly, idempotent, not destructive. Description adds detailed behavioral context: fans out to deps.dev and bundlephobia, returns summary and details, warns about bundlephobia timing (5-30s), and graceful degradation with sources_failed list.

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?

Description is somewhat long but well-structured: composite action first, then usage, returns, ecosystem scope, failure behavior. Every sentence adds value; no fluff.

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 no output schema, the description thoroughly enumerates return fields (summary block, per-advisory detail, links, alternatives), covers ecosystem scope, and explains failure modes. Complete for agent to understand and use 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% with descriptions for both parameters. Description adds beyond schema: acceptance of scoped packages and default to latest version when omitted, which aids correct usage.

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 it is a composite check for assessing an npm package's suitability, with specific verb 'check'. It distinguishes itself from sibling tools by focusing on npm ecosystem and a multi-source composite query.

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

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

Explicitly states when to use: when agent asks about safety, popularity, or size cost. Also provides exclusion: NPM ecosystem only; other ecosystems fall under deps.dev:version directly. Partial failure handling is also described.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds 'Keyless' indicating no authentication needed, and specifies return format (balanced equation, cross-references). This adds some value but does not cover rate limits, pagination, or additional behavioral constraints.

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?

Description is a single sentence that conveys the database, input types, and output. It is front-loaded with key information and avoids unnecessary words. However, it is somewhat dense and could benefit from slight restructuring for readability.

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

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

Given no output schema, the description adequately explains the return format (balanced equation, EC and ChEBI cross-references). It covers the main use case and database source. Missing details on pagination or ordering, but overall sufficient for a search tool with good annotations.

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. The description repeats the same information for the 'query' parameter that is already in the schema description, and does not elaborate on the 'limit' parameter. No additional meaning is provided 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?

Description clearly specifies verb 'Search' and resource 'Rhea database of biochemical reactions'. It lists input types (compound name, ChEBI id, EC number, keyword) and output (balanced equation, cross-references), distinguishing it from sibling 'get_reaction' which presumably retrieves a single reaction by ID.

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?

Description explains what kinds of queries are supported (compound name, ChEBI id, EC number, keyword), giving examples in the schema. However, it does not explicitly contrast with sibling tools like 'get_reaction' or specify when not to use this tool. Usage context is implied but not exhaustive.

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

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

Adds significant context beyond annotations: BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation flag, and per-passage offsets. Annotations already indicate safe read/idempotent behavior, and the description aligns without 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?

Approximately 80 words, front-loaded with purpose and usage, every sentence adds value. No redundancy or 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?

Given no output schema, the description explains return values (top-N passages with offsets and scores) and behavior (truncation). For a 3-parameter tool with clear annotations, it is mostly complete, though additional detail on output format or pagination would elevate it further.

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 covers all 3 parameters with descriptions. The description adds example queries for 'query' and reiterates the max chars for 'text', but does not add substantial new meaning 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 clearly states it performs semantic search inside a fetched record, specifies the resource (text), and distinguishes it from sibling tools like ask_pipeworx_grounded by noting it saves context and returns passages with offsets.

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 explicit when-to-use guidance ('when the record is too big to cram into the prompt') and mentions pairing with ask_pipeworx_grounded. However, it does not explicitly state when not to use or list alternatives beyond the paired tool.

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

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

Annotations indicate mutation, no destruction, and idempotency. The description adds delivery channel constraints (sms 10/day cap, webhook auto-disable after 10 failures) and authentication requirements, but does not discuss idempotency behavior. 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?

The description is a single paragraph with all relevant information front-loaded. It is slightly lengthy but every sentence adds value. Could be improved with bullet points for readability.

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

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

Despite no output schema, the description explains returns (subscription id). It covers prerequisites, type-specific parameters, delivery channels, constraints, and webhook signature verification. Complete for a complex subscription creation tool.

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

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

Schema coverage is 100%, and the description adds significant meaning: type-specific parameter examples (e.g., sec_8k with items codes), delivery channel details, and constraints (phone verification, rate limits).

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

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

The description clearly states 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' It specifies the verb and resource, and distinguishes from siblings like list_subscriptions and unsubscribe.

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 includes prerequisites ('Requires a Pipeworx OAuth account'), lists supported types with specific params, and implicitly siblings serve alternative purposes. It could explicitly state when not to use, but the guidance is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context about the output structure (category-bucketed examples with exact tool arguments) and that it's drawn from a live catalog. No contradictions.

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 somewhat long but front-loaded with key intent and usage. Every sentence adds value, though minor redundancy exists in specifying the topics list. Overall it's clear and efficient.

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

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

Given no output schema, the description adequately explains the return value (category-bucketed example questions with tool+argument shapes). It covers use cases, argument options, and when to invoke, making it complete 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 coverage is 100%, and the description expands on the optional 'topic' parameter by listing example values (finance, pharma, etc.) and explaining behavior when omitted. This adds meaning beyond the schema's minimal description.

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 as an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It distinguishes itself from siblings by recommending use 'FIRST when you do not yet know what Pipeworx can do for you.'

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

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

Explicitly tells when to use ('use this FIRST'), provides calling conventions ('call with no arguments for full spread, or pass topic'), and mentions alternate meta-tools. The guidance is concrete and actionable.

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 indicate idempotent and non-destructive behavior. Description adds value by specifying that the row is deactivated (not deleted) and that historical events remain accessible via 'recent_alerts', which enhances understanding beyond the annotations.

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

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

Two efficient sentences, front-loaded with the core action and purpose. No extraneous information. Every sentence earns its place.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description covers all essential aspects: behavior, ownership, side effects, and linkage to related tool. Fully sufficient for an agent to use 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 covers 100% of parameters with a clear description for 'id'. The description mentions 'by id' but does not add new semantics beyond the schema. Baseline score 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?

Description uses verb 'Cancel' and resource 'a subscription by id', clearly distinguishing from sibling tools like 'subscribe' and 'list_subscriptions'. The action and scope are specific and 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?

States ownership enforcement ('you can only cancel your own subscriptions'), providing clear context for when to use. Implies that the caller must own the subscription. Lacks explicit when-not-to-use or direct alternatives, but the guidance is adequate for this simple tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds critical behavioral nuance: the automatic routing between structured and grounded pipelines, the detailed verdict list, and the crucial distinction between 'could_not_verify' (a failed check, not evidence) and 'unsupported' (no source exists). This significantly exceeds what annotations 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 description is longer than typical but well-structured: trigger phrases, core usage, routing explanation, return values, important caller warnings, and a performance note. It's front-loaded with the purpose statement and examples, and every sentence adds value, though slight trimming could improve scannability.

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 no output schema, the description thoroughly covers the return verdicts, the citation mechanism, error semantics, and the two distinct verification paths. It even explains edge cases like 'could_not_verify' and 'unsupported' in enough detail for an agent to handle results correctly. This is complete for the tool's 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?

Though schema coverage is 100%, the description adds meaningful context beyond the schema: tolerance_pct's interaction with claim wording, the override semantics, and concrete guidance (set 1-2 for hallucination detection). It also explains the default cap at 5%, which the schema alone doesn't imply.

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 concrete trigger phrases and explicitly states the tool's verb+resource: 'natural-language claim verification against authoritative sources.' It clearly distinguishes from sibling tools by focusing on fact-checking claims, and mentions the two distinct verification paths (structured SEC EDGAR vs grounded).

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 an explicit when-to-use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also separates company-financial claims from other claims, but does not name specific alternatives or provide when-not-to-use guidance. The 'Replaces 4–6 sequential calls' hints at efficiency but not exclusion.

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