Decodo

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it probes LLMs, requires a BYO key for Anthropic, and returns per-model details. This adds context beyond annotations, though it doesn't address rate limits or costs.

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 approximately 3 sentences, front-loading the purpose and key details. Every sentence adds value without redundancy or 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 explains the return format: 'Returns per-model {score, confidence, signals, raw_response} + a combined view.' It covers purpose, parameters, and output sufficiently for a tool with comprehensive 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% with good parameter descriptions. The description adds value by explaining the default model, the optional nature of models and _apiKey, and the purpose of context. This goes beyond the 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 'Probe one or more LLMs for what they know... and score visibility (0-100) per model.' It uses a specific verb, identifies the resource (LLMs), and distinguishes from sibling tools like entity_profile or 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 clear use cases: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains when to use the _apiKey parameter. However, it does not explicitly state when not to use the tool or mention alternatives.

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

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

Annotations already declare the safety profile (readOnly, openWorld, idempotent, non-destructive). The description adds meaningful behavioral context: it routes to the right tool, returns structured answers with stable citation URIs, works on every tier, and is one fast call. This goes beyond what annotations provide, though it doesn't disclose limitations like rate limits or failure modes.

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

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

The description is long but every sentence adds value: usage priority, routing behavior, citation URIs, trigger phrases, examples, alternatives, and scope of data sources. It is front-loaded with 'PREFER OVER WEB SEARCH' and structured to guide decision-making efficiently.

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

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

Given this is a complex meta-tool routing across many sources, the description covers purpose, usage, examples, alternatives, output format (structured answer with citations), and integration with siblings. No output schema exists, so the description sufficiently communicates return value characteristics and behavioral scope.

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 detailed descriptions for each alias. The description adds little beyond the schema, only clarifying that 'question' accepts aliases (already in schema). The examples in the schema give usage context, so the description does not need to compensate. 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 explicitly states this tool routes questions to one of 5,406 tools across 1,403 sources and returns structured answers with citation URIs. It clearly distinguishes itself from siblings by naming alternatives (ask_pipeworx_grounded, deep_research) and specifying when to step up.

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: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and lists specific use cases with examples. It also states when NOT to use it and alternatives ('Step up only when needed...'), covering when/when-not with concrete 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 annotations (readOnlyHint, idempotentHint, etc.), the description discloses the beta testing behavior: candidate improvements enabled live, currently inactive, and that it is a full working router with no fallback. This adds useful context about potential variability during active tests.

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?

Five sentences, each earning its place: beta identity, current state, usage instruction, comparison to stable router, and clarification that it's not a fallback. Information is front-loaded with the key fact and structured logically.

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 variant of an existing tool, the description is complete: it explains the relationship to ask_pipeworx, the experimental nature, current status, how to use it, and that it's fully functional. No output schema exists, so return values need no elaboration.

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 description does not add parameter-level guidance, but the input schema fully documents the 'question' parameter and all six aliases with 100% coverage. Baseline 3 is appropriate since the schema carries the semantic weight.

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

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

The description clearly identifies this as the beta version of ask_pipeworx, an identical universal router with 5,406 tools, same arguments, and same response shape. It distinguishes it from the stable ask_pipeworx by the experimental routing improvements, and the phrase 'Use it exactly like ask_pipeworx' reinforces its purpose.

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

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

Explicitly states when to use: 'when you want the newest routing', and explains results are compared against the stable router to decide merges. It implies the alternative (stable ask_pipeworx) and clarifies that the current behavior matches ask_pipeworx exactly, giving clear context.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description reveals important behavioral traits: it extracts only from the tool result, returns evidence as verbatim quotes, has a structured refusal mechanism with specific reasons, and costs an extra LLM call. These details are not inferable from annotations and significantly aid safe invocation.

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

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

Every sentence in the description contributes unique value: purpose, process, output structure, refusal reasons, use cases, and cost comparison. It is well-structured with a clear flow from 'what' to 'when' and 'trade-off', and maintains a dense but readable format.

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

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

Despite having no output schema, the description fully explains the return payload on success and all refusal reasons. It also covers the tool's internal routing, source count, cost implication, and example use cases, making the description self-sufficient for an agent to decide and use the tool correctly.

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

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

The input schema covers 100% of parameters with descriptions for the 'question' parameter and alias listing. The tool description adds no extra parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly defines the tool as a 'hallucination-resistant answer mode' with a specific verb ('extracts the answer') and scope ('high-stakes reads'). It explicitly differentiates from sibling ask_pipeworx by explaining it uses the same routing but grounds its answer solely in tool results. This makes the purpose unambiguous and distinguishable.

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: 'whenever an answer will be quoted, cited, or acted on... must not invent facts.' It also provides an exclusion: 'prefer ask_pipeworx for casual lookups' and notes the cost trade-off of one extra LLM call. This gives clear when-to/when-not-to guidance with a named alternative.

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 false. The description goes far beyond by detailing resolution matching confidence, parent event extraction, news fallback fields, safety short-circuits for low-confidence matches, closed market handling, wide-spread illiquidity, and cancellation rule parsing. This comprehensive behavioral disclosure adds immense value 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?

The description is front-loaded with the core purpose and use cases. It uses bullet points and sections for classifiers, fan-out examples, response shapes, safety, etc. Every sentence adds unique, non-redundant information. Despite its length, it is well-structured and efficient for an AI agent to parse.

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

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

Given the complexity of the tool (multiple fan-outs, classifiers, response structures, edge cases) and the absence of an output schema, the description is exceptionally complete. It covers inputs, processing logic, all output fields (market, analysis, evidence, resolver contract, parent event, news fields, safety mechanisms, cancellation rules), making no critical gaps.

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

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

The input schema has 100% coverage with descriptions for all three parameters. The description adds extra context: examples for 'market' (slug, URL, question text), meaning of 'depth' (quick vs thorough) with defaults, and 'include_raw' with recommendations and payload size implications. This significantly enhances understanding beyond the 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 the tool researches a Polymarket bet by pulling Pipeworx data in one call. It specifies the purpose with verbs like 'Research', 'pull', 'resolves', 'classifies', 'fans out', and 'returns', and distinguishes from sibling tools by explicitly stating use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This makes the purpose highly specific and differentiated.

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 and behavioral conditions (e.g., low-confidence short-circuit, closed markets, wide spreads, cancellation rules). However, it does not explicitly contrast with sibling tools like 'polymarket_edges' or 'ask_pipeworx', leaving some room for ambiguity. The 'Use for' statements give clear context, but alternative tools are not named.

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 mark it as read-only, idempotent, non-destructive, and open-world. The description adds valuable behavioral details: handles off-calendar fiscal years, returns sorted results by primary metric, and includes citation URIs. 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 front-loaded with trigger phrases and key details. While somewhat long (multiple sentences), each sentence adds meaningful guidance without redundancy. Could be slightly more concise but still effective.

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

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

No output schema exists, but the description explains that it returns paired data and citation URIs per entity. It covers data sources for both types and sorting behavior. Given the tool's complexity (2-5 entities, multiple data points), the description is complete and 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 clear descriptions for both parameters. The description reinforces valid values (tickers/CIKs for companies, drug names for drugs) and constraints (maxItems 5, minItems 2) but does not add new semantics beyond the schema.

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

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

The description clearly states the tool's purpose: side-by-side comparison of 2-5 companies or drugs. It provides trigger phrases like 'X vs Y' and 'which is bigger', and distinguishes it from sibling single-entity lookup tools like entity_profile.

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

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

Explicitly instructs to prefer over sequential lookups. Provides context for when to use (comparison, ranking, head-to-head) and what data each type returns (company: financials from SEC EDGAR/XBRL; drug: FAERS adverse events, FDA approvals, trials).

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 context beyond annotations: explains BYOK credential format, mentions output is JSON with specific fields. No contradictions with annotations (readOnlyHint, idempotentHint, etc.).

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: first defines purpose and output, second specifies inputs with example. Front-loaded and no wasted words.

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

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

Given no output schema, description sufficiently explains return fields. Covers authentication, input options, and includes an example. Complete for a 5-parameter scraping 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 has 100% description coverage, so baseline 3. Description adds value by showing example usage and emphasizing the _apiKey format, improving understanding beyond 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?

Clearly states it gets structured Amazon product data via Decodo, listing specific data fields. Distinguishes from siblings like decodo_google_search by focusing on product data from Amazon URLs/ASINs.

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

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

Provides clear input options (URL or ASIN) and example, but does not explicitly differentiate from sibling tools like decodo_scrape or state when not to use.

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, etc.) are consistent. Description adds valuable behavioral details: uses rotating proxies, returns structured results (position, title, url, snippet), related searches on success, and BYOK credential format. 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?

Two short sentences plus an example; every part adds value. Front-loaded with purpose. 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?

No output schema, but description explains return structure (organic results fields and related searches). Covers failure case (parsing succeeds). For a scraping tool with 5 well-documented params, 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?

Schema has 100% coverage of parameters. The description reinforces key parameters via example (_apiKey and query) and explains _apiKey format. Adds context about output structure, but does not add extensive parameter-specific info beyond 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?

Clearly states it scrapes Google search results via Decodo, specifying the verb ('scraping'/'runs a Google search') and resource ('Google search'). Distinguishes from sibling tools like decodo_amazon_product and decodo_scrape.

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

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

Provides clear context: use for Google search with rotating proxies, returns organic results. Includes an example call. Does not explicitly state when not to use, but sibling names imply alternatives. Good enough for typical use.

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=true and destructiveHint=false, so the tool is non-destructive. The description adds value by disclosing that the tool 'handles anti-bot pages' and requires an API key via _apiKey, which are behavioral traits not covered by annotations. 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 extremely concise: three sentences covering purpose, optional parameter guidance, and an example. It is front-loaded with the main function and adds no fluff. 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 5 parameters, 100% schema coverage, no output schema, and multiple sibling tools, the description covers the essential usage scenarios. Return format is not detailed (no output schema), but the markdown option hints at output type. Overall, it is sufficiently complete for an agent to use effectively.

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 meaningful context beyond the schema: for render_js, it explains 'headless-browser rendering'; for markdown, 'clean LLM-ready markdown'; for _apiKey, it clarifies the format and provides an example. These embellishments improve understanding.

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: 'Scrape any web page through Decodo rotating proxies and return its content.' It specifies the action (scrape), target resource (any web page), and mechanism (rotating proxies). It stands out from sibling tools like decodo_amazon_product and decodo_google_search, which are more specialized, making the general scope evident.

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 guidance on when to use key parameters: 'use render_js:true for JavaScript-heavy sites' and 'markdown:true for clean LLM-ready markdown'. It also includes an example invocation. While it lacks explicit 'when not to use' instructions, the context is clear enough for an agent to decide.

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. The description adds substantial context beyond these: account/paid-tier requirements, parallel decomposition into 5,406 tools, return packet structure (verbatim evidence, confidence, source, fetched_at, citation), gaps[] instead of invented answers, hop/citation_uri fields, contradictions[] for standard/thorough, semantic excerpting, and latency expectations. 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 long but densely packed with actionable information, front-loaded with the most critical caveats (account requirement and fallback). Some redundancy exists between the 'findings packet' description and the later 'hop field and citation_uri' explanation, but the overall structure is logical with clear sections and concrete examples. 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 complexity (two params, rich annotations, no output schema), the description is remarkably complete. It fully describes the return format (findings packet, gaps[], contradictions[], hop, citation_uri), explains semantic excerpting for large records, covers edge cases (current-news topics returning mostly empty gaps), and provides latency expectations for all depth levels. The agent has everything needed to invoke the tool 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%: both question and depth have detailed descriptions, including enum values for depth with facet counts and hop behavior. The description supplements this by explaining depth-specific behaviors (gap recovery, paid plan requirement for 'thorough', latency expectations) and clarifying that broad/multi-part questions are acceptable. This goes beyond the schema, though the schema already carries significant weight.

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

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

The description uses a specific verb+resource+scope: 'Grounded multi-source research across Pipeworx's 1403 STRUCTURED data sources... in ONE call.' It clearly distinguishes itself from siblings by explicitly contrasting with ask_pipeworx for single lookups and current-news topics, and by mentioning that it is not open-web search.

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

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

Explicit when-to-use guidance is provided: 'Best for broad/multi-part questions over structured data'. It names alternatives: 'For a single lookup use ask_pipeworx' and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'. It also covers account requirements and fallback behavior when not signed in.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable behavior: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas — each result is ready to call directly'. 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?

Description is moderately concise, front-loads purpose, and provides enough detail without excessive redundancy. Could be slightly shorter but effectively structured.

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

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

For a discovery tool with 6 params (mostly aliases) and no output schema, the description covers purpose, usage, output format, and sample queries. Provides complete context 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 has 100% coverage with descriptions. Description adds minimal value beyond schema: mentions 'top-N' implying limit parameter, but schema already explains limit. 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 verb 'Find tools' and resource 'tools', lists numerous specific domains (SEC filings, financials, etc.), and distinguishes from siblings by advising to call this FIRST to see available options.

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 you need to browse, search, look up, or discover what tools exist' and advises 'Call this FIRST when you have many tools available'. Clear context but no explicit when-not to use 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?

Annotations already declare read-only, open-world, idempotent, and non-destructive. Beyond that, the description details data sources, return fields, error handling (patents API sunset soft-fail), and input constraints. 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 informative but slightly verbose for a 5. However, it is well-structured with examples upfront, followed by details. Each sentence adds value, so it earns a high score, but could be tightened.

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

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

Given the complexity (multiple sources, fallbacks, return fields), the description is comprehensive. It lists return fields, explains patent API sunset behavior, and covers input restrictions. No output schema exists, but the description effectively compensates.

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. The description adds critical context: type only supports 'company', value must be ticker or zero-padded CIK, and explicitly states names are not supported—going 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 provides a 'full cross-source profile of a US public company in ONE parallel call', with specific examples like 'Tell me about X' and 'company profile for Microsoft'. It distinguishes from siblings by emphasizing holistic view over chaining single-purpose 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?

Explicitly tells when to use: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view'. Also provides clear input requirements (ticker or CIK, not names) and directs to resolve_entity if only a name is available.

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 destructiveHint=true and readOnlyHint=false, consistent with deletion. Description adds context about clearing sensitive data and stale context. Could mention if deletion is permanent or reversible, but overall good.

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

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

Three sentences efficiently convey purpose, usage, and relation to siblings. No wasted words.

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

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

Tool is simple with one parameter and no output schema. Description fully covers what the agent needs to know for correct invocation.

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

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

Schema coverage is 100% with one parameter 'key' described as 'Memory key to delete'. Description doesn't add new meaning beyond schema, so baseline 3 is appropriate.

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

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

Description states 'Delete a previously stored memory by key', providing specific verb (Delete) and resource (memory by key). It distinguishes from siblings 'remember' and 'recall' by mentioning them, making the tool's purpose clear.

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

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

Explicitly says 'Use when context is stale, the task is done, or you want to clear sensitive data' and suggests pairing with 'remember' and 'recall', offering clear when-to-use and 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 details the process: fetching the page, extracting title/description/key links, and emitting standard markdown. Annotations already indicate read-only, idempotent, non-destructive, 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?

Three concise sentences: action and output, process steps, use cases. No filler, every sentence earns its place.

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

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

The description explains the output format ('single text blob', 'standard llms.txt markdown') and process, compensating for the lack of an output schema. Parameter details are covered by the schema. 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?

Schema coverage is 100% with descriptions for both parameters. The description adds an example URL format and mentions max_links defaults ('Maximum number of link entries to include (default 25, max 50)'), but this largely echoes the schema. Minimal added 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 generates an llms.txt file from any URL, specifying the action, resource, and output format. It is distinct from sibling tools which are general search/scrape functions.

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 lists explicit use cases (client site indexing, own project, competitor auditing), giving clear context for when to use. It does not explicitly mention when not to use, but the provided examples are 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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns specific fields and defaults to active subscriptions, which aids 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 sentences, front-loaded with the core action and return fields, then usage advice. No unnecessary words.

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

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

For a simple list tool with no output schema, the description explains the returned fields, purpose, and usage, covering all necessary context.

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 a clear description for the only parameter (include_inactive). The tool description does not add extra meaning 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 clearly states it lists the caller's active subscriptions and mentions returned fields (id, type, etc.), differentiating it from sibling tools like subscribe 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 provides specific use cases (review before adding more, find id to cancel), guiding when to use. It doesn't explicitly exclude scenarios, but the guidance is clear and 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?

Behavioral traits like rate limiting (5 per day), no cost, not counting against quota, and team reading frequency are disclosed. Annotations provide no such details, so the description adds significant value.

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

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

The description is well-structured and front-loaded with the core purpose. All sentences are informative, though slightly verbose for a tool description. A bit more conciseness would improve it.

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 what happens after submission (team reads daily, affects roadmap). It covers the tool's complete context, including constraints and expectations.

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 covers 100% of parameters with descriptions, the description adds extra context: message length guidance (1-2 sentences, 2000 chars), and specific instructions for each type (e.g., 'bug = something broke...'). It also advises not to paste end-user prompt.

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 is for sending feedback to the Pipeworx team, with explicit categories (bug, feature, data_gap, praise). It distinguishes itself from siblings as the only dedicated feedback 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 explicitly tells when to use the tool (for bugs, missing features, data gaps, praise) and what not to do (don't paste end-user prompt). It also mentions rate limits and daily digest reading.

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?

Discloses caching (5min-1h), aggregation source (CF analytics-engine), data privacy (no PII). Annotations already indicate read-only, idempotent, non-destructive; description adds concrete behavioral details.

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, front-loaded with purpose, then use cases, then technical details. No redundant or vague phrasing.

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, description specifies return structure (top tools, packs, volume) and caching behavior. Sufficient for a simple 1-param 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 covers 100% of parameter with enum and description. Tool description adds interpretive context (shorter windows for hot trends, longer for steady-state). Exceeds baseline 3.

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

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

Clearly states it returns top tools, top packs, and total call volume over recent windows. Distinguishes from siblings like 'discover_tools' by focusing on trending usage metrics.

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 lists three use cases: discovering hot data sources, confirming popular tool, checking alignment. Lacks explicit when-not-to-use but provides clear context.

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

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

The description adds extensive behavioral context beyond the annotations, explaining internal logic like monotonicity checks, partition checks, semantic anchor, partition filter, and fill check against live CLOB depth. There is no contradiction with the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint 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 for each mode and additional details, but it is somewhat lengthy. However, every sentence adds value, and the key information 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?

Given the tool's complexity and lack of an output schema, the description thoroughly covers input modes, internal checks, response structure (opportunities array, partition_check, fill check), and trade guidance. It also references the sibling tool for custom sizing, making it 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 coverage is 100%, and the description adds meaning: it explains that 'event' accepts a Polymarket event slug or full URL, and 'topic' takes a seed question for cross-event scanning. It also connects parameter use to mode behavior, enhancing understanding.

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: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between the three modes (no args, event, topic) and explains what each does, differentiating it from siblings like polymarket_fill_risk.

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 usage guidance is provided: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. It also warns when not to trade based on fill check results and directs to a sibling for custom sizing.

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, destructiveHint. The description adds extensive behavioral context: KV caching for 1h, the detailed edge computation (lognormal barrier, GDELT, partition_overround with correction and placeholder filters), and response structure including diagnostics for empty segments. 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 very long and detailed, with technical model explanations. It is front-loaded with purpose but then dives deep. While structured with sections like by_segment and diagnostics, the verbosity may hinder quick parsing. Every sentence is informative but could be more concise.

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 (9 parameters, no output schema), the description explains the response top-level fields (by_segment, fed_candidates, _diagnostics) and includes edge calculations. It compensates for lack of output schema by describing returned fields. However, it could mention pagination or full response structure more clearly.

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 provides additional context like 'Tradeable-edge filter' for max_spread_pp and min_liquidity, but the schema already describes them adequately. The parameter info in the description does not significantly add beyond what the schema 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?

Description clearly states it scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, and distinguishes itself from siblings by specifying three model families and segments like MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT. The title 'Polymarket Edges' is descriptive.

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 says it's built for 'what should I bet on today' and that agents discover opportunities without paging hundreds of markets. It explains tradeable-edge knobs for filtering. However, it does not explicitly say when NOT to use this tool or compare directly to siblings like polymarket_arbitrage or polymarket_edge_tracker, which would improve 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?

Adds extensive detail beyond annotations: describes response structure (tracked, expired, snapshot_dates), trend computation, and that decay is from daily closes not intraday. Annotations already indicate safe read operation; description complements well.

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?

Long but well-organized: purpose, args, response format, and limitations clearly separated. Some redundancy (e.g., repeated 'default 14' in description and schema) but efficient overall.

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

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

Thoroughly covers expected behavior: inputs, output fields, edge cases (gaps), and limitations. No output schema but response structure detailed enough. Annotations provide safety context.

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 both parameters with descriptions; description adds context like default values, clamping, and snapshot family concept. Since schema coverage is 100%, baseline is 3, but the extra context justifies a 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?

Clearly states it provides edge persistence and decay telemetry, answering 'how long has this edge existed and is it shrinking?'. Distinguishes from sibling polymarket_edges by focusing on historical time-series rather than 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?

Explains when to use: to differentiate fresh vs old edges. Mentions limits (60-day TTL, snapshot start date). Does not explicitly list alternatives but implies use case; could be more direct about when not to use.

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 significant behavioral context beyond the annotations (which indicate read-only, open-world, idempotent, non-destructive). It details the ladder-walking logic, return fields (top_of_book, vwap_fill_price, slippage_pp, verdict, etc.), and risks like forced_directional_risk. 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 relatively long but well-structured with clear sections for single-market and basket modes, plus usage guidelines. It is front-loaded with the core purpose and uses bold headers for emphasis. While dense, each sentence adds value; minor verbosity is justified by the tool's 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 tool's complexity (two modes, multiple return fields, no output schema), the description is remarkably complete. It explains inputs, outputs (listing return fields), behavioral details, and risks. The description enables an agent to fully understand what the tool does, when to use it, and what results to expect.

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%, but the description adds substantial meaning: it explains how size_usd is interpreted differently for buys vs sells and basket vs single-market, the auto behavior of side in basket mode, and the requirement for either market or event. This goes beyond the schema's basic 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 clearly states the tool performs a realizable-vs-theoretical edge check against live CLOB order-book depth, with explicit modes (single-market and basket) and specific use cases. It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by specifying when to use this tool before acting on 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 tells when to use this tool: before any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or polymarket_edges trade above ~$500. It explains the risks of not using it (theoretical overround not capturable, partial basket fills creating directional risk), providing clear guidance on alternatives and context.

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

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

Disclosures beyond readOnlyHint, openWorldHint, idempotentHint, destructiveHint include safety fields (compatibility_warning, temporal_alignment, skipped_cross_type) and explains their meaning. 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 relatively long but well-structured with sections for purpose, modes, response, and safety fields. Every sentence adds value, though could be slightly more concise.

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 values (leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). Sufficient 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?

Schema coverage is 100%, so baseline is 3. Description adds significant value by explaining the two modes and how parameters interact (e.g., overrides for explicit ticker/slug).

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 computes cross-venue spreads between Kalshi and Polymarket for the same resolving question, and distinguishes two modes (topic shortcuts vs explicit ticker/slug). It differentiates from siblings like polymarket_arbitrage.

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 describes when to use topic mode vs explicit mode, and warns that most pre-mapped topics return compatibility_warning today, so agents know not to expect tradeable spreads. Provides clear guidance on when not to use.

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, destructiveHint=false, idempotentHint=true. The description adds useful scoping context (anonymous IP, BYO key hash, account ID) and pairing instructions, but the core behavioral profile is already covered by annotations.

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

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

Three concise sentences: first states core function, second explains use case with examples, third adds scoping and pairing. No wasted words, front-loaded with key action.

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 single parameter, full schema coverage, and no output schema, the description provides enough context about what is returned (value or list of keys) and examples of stored data types (ticker, address, notes). Completeness is high.

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 description clarifies that omitting the key lists all keys, which adds meaning beyond the schema's property description. Schema coverage is 100% so baseline is high, and the description enhances it.

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 'Retrieve a value previously saved via remember, or list all saved keys', providing a specific verb and resource. It distinguishes itself from sibling tools 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?

Explicitly tells when to use ('look up context the agent stored earlier... without re-deriving'), provides scoping info, and pairs with siblings remember and forget for complete workflow.

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 (readOnlyHint=true) and idempotent (idempotentHint=true). The description adds useful behavioral details: it explains that setting mark_read:true flags events as read, affecting future calls, and that polls work fine. It also discloses the return format (source, citation_uri, raw event payload). 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 with no wasted sentences. It front-loads the core purpose and then lists key features, filtering options, and an alternative access method. While it is somewhat dense, every sentence adds value. It could be slightly shorter but is well-structured.

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

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

Given that there is no output schema, the description adequately explains what is returned (source, citation_uri, payload). It accounts for all parameters, annotations, and common usage patterns. The tool is simple and read-only, so no additional behavioral details are needed. The description feels complete for its complexity level.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds practical context: explains the effect of mark_read, specifies the default and range for limit (1-200, default 50), clarifies that since is an ISO timestamp, and explains unread_only filters on read_at null. This goes beyond the schema's brief 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 starts with a clear verb-resource pair: 'Pull fired events from your subscription feed.' It specifies the action (pull), the resource (alerts from subscription feed), and distinguishes itself from sibling tools like 'subscribe' (which manages subscriptions) and 'list_subscriptions' (which lists them). The scope is explicit: 'most recent alerts.'

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: for polling and retrieving alerts. It provides filtering options and mentions an alternative method ('the same feed is also at GET registry.pipeworx.io/alerts.json for scripts and dashboards'). However, it does not explicitly state when not to use it or compare with siblings like 'recent_changes'.

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 rich behavioral context beyond the annotations: it explains the data sources (SEC EDGAR, GDELT→GNews fallback, USPTO with soft-fail), date parsing, return structure (changes grouped by source, total_changes, citation URIs), and the multi-tool parallel call. No contradictions with annotations (readOnlyHint, openWorldHint, idempotentHint, non-destructive are all consistent).

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 and well-structured: it opens with illustrative examples, states the core function, details sources and fallbacks, explains the parameter, and explicitly differentiates a sibling. 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 sources, fallback logic, date handling, no output schema), the description is remarkably complete. It covers all key behaviors: source selection, fallback behavior, date format flexibility, output structure, and explicit comparison with entity_profile. An agent can confidently decide to invoke this tool based on this description.

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

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

Schema description coverage is 100%, so the schema already documents parameters well. The description adds practical context (e.g., relative date shorthands, ticker vs CIK, typical monitoring window), but the marginal benefit is moderate. 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 is a 'change feed for a company in the last N days/weeks/months' and distinguishes it from the sibling tool 'entity_profile' which provides a static profile. It also covers the multi-source fan-out, making the tool's purpose very specific and actionable.

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 tells the agent when to use this tool (for temporal changes) and when not to ('Use entity_profile instead when you want the static profile'). It also provides example queries and guidance on the 'since' parameter, including typical values like '30d' or '1m'.

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 non-readOnly (write operation) and idempotent. Description adds scoping by identifier, persistence differences between authenticated and anonymous users, and 24-hour retention for anonymous sessions. Provides useful behavioral context 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?

Concise and well-structured: first sentence states core purpose, then usage guidance, then behavioral details. No unnecessary words.

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

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

For a simple write tool with no output schema, the description is complete. It explains what is stored, scoping, persistence, and how to retrieve/delete. No gaps.

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

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

Schema description coverage is 100% with clear parameter descriptions. The description does not add additional semantics beyond the schema, meeting baseline expectation.

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 'Save data the agent will need to reuse later' and specifies key-value storage. It distinguishes from siblings by referencing recall and forget tools for retrieval and deletion.

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 usage guidance: 'Use when you discover something worth carrying forward' with concrete examples (resolved ticker, target address, etc.). It also directs to pair with recall and forget for lifecycle management.

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 false. The description adds value by explaining that each call cascades through several lookup endpoints internally and returns citation URIs, which is 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?

The description is compact and efficient, starting with natural language examples followed by the core purpose, usage instruction, and type details. Every sentence earns its place 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?

Despite no output schema, the description details return values for each type (e.g., ticker, CIK, company name, citation URI for company). It covers auto-disambiguation and the fact that it replaces multiple manual lookups, providing complete context for usage.

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

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

Schema coverage is 100% and describes both parameters. The description adds examples for each type (ticker, CIK, name for company; brand or generic for drug), providing extra context 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's purpose: resolving a spoken name to a canonical identifier. It provides natural language examples and explicitly says 'Use FIRST whenever you have a name but need an ID.' It distinguishes from sibling tools by detailing supported types and unique capabilities like auto-disambiguation.

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 advises to use this tool first when a name needs an ID. It implies that if you already have an ID, you wouldn't use it. While it doesn't list alternative tools for when not to use, the context is clear enough for an agent to decide.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds value by detailing the probing process ('Probes each entity... with ai_visibility_check'), ranking behavior, and output structure (score, confidence, signal density), which exceeds annotation coverage.

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

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

Four concise, front-loaded sentences with no fluff. Each sentence contributes: overall purpose, how it works, a usage example, and output format.

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 fully explains return format (ranked list with score, confidence, signal density). Combined with clear purpose, usage, and parameters, the tool is completely contextualized for an agent.

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

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

Schema description coverage is 100% for all 4 parameters, so baseline is 3. The description adds extra meaning by noting 'First entry treated as the subject for narrative' and that context 'disambiguates common names', enriching 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 uses specific verb-resource pairs ('Compare AI visibility across multiple entities', 'Probes each entity... with ai_visibility_check, ranks by score'), clearly distinguishing from siblings like ai_visibility_check (single entity) and compare_entities (generic).

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 explicit context ('Useful for competitive AI-marketing audits') and an example question, implying when to use. It does not explicitly mention alternative tools but the sibling ai_visibility_check is inferable as the single-entity counterpart.

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, open-world, and idempotent behavior. Description adds that bundlephobia's first measurement may take 5-30s and that partial failures degrade gracefully, outlining expected behavior 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?

The description is thorough but slightly long. However, every sentence adds value and the main purpose is front-loaded. Could be more concise, but still effective.

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 exhaustively lists all return fields (summary block, advisories, links, versions). Also covers edge cases like partial failures and ecosystem limitations, making it self-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?

Both parameters are fully described in the schema. Description adds practical details: package accepts scoped packages, version defaults to latest, and explains the purpose of each parameter (e.g., 'Specific version to check').

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?

Clearly states the tool's purpose: a composite check for npm packages using deps.dev and bundlephobia. Differentiates from siblings by specifying ecosystem scope.

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 (agent questions about safety/popularity/size) and when not to use (non-npm ecosystems, which are handled by another tool). Provides clear 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?

Discloses embedding model, windowing strategy, character cap, truncation behavior, and return format (offsets, similarity scores). Adds significant value beyond annotations that already mark it as read-only and idempotent.

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 and front-loaded with purpose, but includes technical details (BGE-base-en, window size) that might be slightly verbose for some agents. Still efficient overall.

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

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

Describes return values, limitations, sibling pairing, and usage context. With no output schema, it sufficiently covers behavioral expectations.

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 meaningful usage guidance (e.g., example queries, text source context, limit range). While it reinforces schema details, it provides extra clarity.

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

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

The description clearly identifies the tool as performing semantic search inside a fetched record, using specific verbs and examples. It distinguishes itself from siblings like ask_pipeworx_grounded by focusing on internal passage retrieval.

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 the record is too big to cram into the prompt') and pairs with a sibling tool. No exclusion of alternatives, but clear context for usage.

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

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

The annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: the necessity of an OAuth account, phone verification for SMS, a 10/day SMS cap, webhook auto-disable after 10 failures, and the always-on feed. It does not discuss idempotency, but overall adds significant value 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?

The description is front-loaded with the primary purpose and expands with necessary details. It is fairly long but each sentence adds value. Could be slightly more concise, but overall well-structured.

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

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

Given the complexity of 3 parameters (with nested objects and enums), the description covers all subscription types, their params, delivery channels, prerequisites, and limits. No output schema exists, but the return of subscription id is mentioned. Complete for a 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?

With 100% schema coverage, baseline is 3. The description enriches each parameter with concrete examples and behavioral details (e.g., sec_8k items codes, polymarket_edge min_spread_bps, delivery channel constraints). This goes well 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 clearly states the tool's purpose: 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This is specific and distinguishes it from sibling tools like list_subscriptions, unsubscribe, and recent_alerts.

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 prerequisites ('Requires a Pipeworx OAuth account'), supported types, and delivery options. It implies when to use (to set up alerts) but does not explicitly exclude alternatives like list_subscriptions or recent_alerts. Still clear enough for selection.

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

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

Beyond annotations (readOnly, openWorld, idempotent, not destructive), the description adds that results are drawn from a live catalog of thousands of tools and include exact tool+argument shapes. 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 front-loaded with common user questions and is well-structured, though slightly lengthy. Each sentence adds value, but minor trimming could be possible.

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

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

For a tool with one optional parameter and no output schema, the description fully explains what it returns (categories, examples) and when to use it, making it complete for its purpose.

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 rich context: examples of topic values, the effect of omitting topic vs. providing one, and the kind of results expected.

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

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

The description uses specific verbs like 'returns category-bucketed example questions' and explicitly positions it as the onboarding entry point, distinguishing it from sibling tools like ask_pipeworx or discover_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?

Explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you', and describes when to use topic vs. no arguments. However, it does not explicitly list when not to use it.

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

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

Adds significant value beyond annotations: describes deactivation vs deletion, ownership check, and impact on historical data. Annotations only indicate non-destructive and idempotent but not these specifics.

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, zero waste. Every sentence provides essential information: action, constraint, and side effect.

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?

Completely covers the tool's purpose, behavior, and side effects. Absence of output schema is not an issue as return is implicit. References recent_alerts for related functionality.

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?

Single parameter 'id' is fully described in schema (UUID from subscribe). Description does not add much, but schema coverage is 100%, so baseline 3 is exceeded due to clarity.

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?

Clearly states the action (cancel subscription by id), specifies the resource, and distinguishes from sibling tools like subscribe and list_subscriptions by noting the deactivation behavior.

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 mentions ownership enforcement (only cancel own subscriptions) and notes that historical events remain available via recent_alerts. Does not explicitly state when not to use, but context is clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral details: two processing paths, returned verdict/value/citation/reasoning, and mentions it replaces multiple sequential calls. 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?

Description is packed with useful information and front-loaded with query examples. Slightly verbose but every sentence adds value; could be slightly more concise without losing details.

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

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

Given only 2 parameters, no output schema, and rich annotations, the description is fully complete: covers return format (verdict, value, citation, reasoning), fallback behavior, and example claims. No gaps.

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

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

Schema coverage is 100% with good parameter descriptions. Description adds meaning beyond schema: explains tolerance_pct override and default behavior, provides claim examples, and clarifies the structured vs. grounded pipeline routing.

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: natural-language claim verification against authoritative sources. It provides specific verb+resource (validate/verify claim) and distinguishes from siblings by focusing on fact-checking rather than generic queries like ask_pipeworx.

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 'Use whenever the agent needs to check whether something a user said is factually correct' and explains when the SEC EDGAR path vs. grounded pipeline is used. Does not explicitly list when not to use, but context is clear.

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