Pirate Weather

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds crucial behavioral details: default model, free vs. BYO key for Anthropic, and the structure of the return value (per-model fields + combined view). 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 three sentences, each serving a distinct purpose: purpose, details about parameters and pricing, return format, and use cases. No redundant 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 4 parameters and no output schema, the description adequately covers the return format (per-model fields + combined view) and parameter behavior. It could mention rate limits or pagination, but these are not critical for this tool's 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?

Schema description coverage is 100%, but the description adds value beyond the schema: it states the default model, explains that _apiKey is passed through to Anthropic, and clarifies that context helps disambiguate. This enriches the parameter 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 starts with a specific verb ('Probe') and resource ('LLMs'), clearly stating the action and target. It distinguishes itself from sibling tools by focusing on visibility scoring for brands, which is unique among the listed tools.

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

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

The description provides clear usage contexts: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' However, it does not explicitly mention when not to use this tool or list alternatives, though the context is clear enough for an agent.

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. The description adds behavioral context: it routes questions to one of 5,529 tools across 1,455 sources, fills arguments, and returns structured answers with stable pipeworx:// citation URIs. This explains the internal routing behavior and output format beyond the annotations, with no contradictions.

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

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

The description is longer than typical but every section serves a purpose: preference directive, tool capabilities, usage triggers, examples, and escalation paths. It is front-loaded with the 'PREFER OVER WEB SEARCH' directive. Slightly verbose but well-organized and information-dense.

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

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

No output schema exists, so the description compensates by explaining the return format ('structured answer with stable pipeworx:// citation URIs'). It covers the full range of supported domains, gives concrete examples, and clarifies relationships with sibling tools. This is complete for a tool of this complexity.

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

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

Schema coverage is 100% for the 'question' parameter, with aliases q, text, input, query, prompt documented. The description adds no additional parameter-level detail, but it does provide example questions. Since the schema already fully documents parameters, 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 that ask_pipeworx answers factual questions about current/historical data across many domains, routing to thousands of sources and returning structured answers with citations. It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by naming explicit alternatives and use cases.

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

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

The description provides explicit guidance: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and gives when-to-step-up examples (use ask_pipeworx_grounded for hallucination-resistant single answers, deep_research for broad/multi-part questions). It also covers breaking news scenarios. This is exemplary usage 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 substantial context beyond the annotations: candidate routing improvements can be enabled live, no candidate is currently active (last retired on 2026-07-26), and it is a full working router with no fallback. This clarifies the experimental nature and current equivalence to the stable tool.

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

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

The description is front-loaded with the beta identity and current state, then provides usage guidance and clarification. It is somewhat dense but each sentence contributes meaning; the 'falls back to nothing' clause is useful to prevent misunderstanding.

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 single-question router with rich annotations, the description covers identity, current status, usage scenario, and behavioral expectations. It also references the stable sibling for response shape, making it sufficiently complete for an agent to decide when to invoke it.

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

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

The schema covers 100% of parameters, with all six being aliases for 'question' and fully documented. The description only generically mentions 'same arguments' and adds no per-parameter semantic value 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 identifies this as a beta version of ask_pipeworx, a universal router with the same 5,529 tools, arguments, and response shape, and distinguishes it from the stable sibling by the experimental routing improvements. It lacks a direct verb phrase like 'answers questions' but references the established ask_pipeworx interface.

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 it exactly like ask_pipeworx when you want the newest routing' and notes that it currently matches the stable router exactly, with results compared against the stable router for merges. This provides clear when-to-use guidance and acknowledges the stable 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?

The description discloses key behavioral traits beyond annotations: it returns a structured result with evidence, confidence, and refusal reasons, and only uses the tool result content (no external knowledge). It lists all refusal reasons explicitly. This goes well beyond the annotations, which already indicate read-only and non-destructive behavior.

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

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

The description is a bit long but every sentence adds value: purpose, behavior, return format, refusal cases, and usage guidance. It is front-loaded with the most important info. Could be trimmed slightly, but the density is justified given 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?

Even without an output schema, the description fully specifies the return shape (answer, evidence, confidence, source, fetched_at, refusal_reason) and all possible refusal reasons. It also covers cost trade-offs and use cases, making it complete for an agent to invoke 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 description coverage is 100% — all six parameters are aliases for 'question' and are fully described in the schema. The description adds no additional parameter semantics, but it doesn't need to since the schema is complete. Baseline of 3 applies.

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

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

The description clearly states a specific verb+resource: it is a 'hallucination-resistant answer mode' that routes through the same underlying tools as ask_pipeworx but extracts answers only from the tool result. It explicitly distinguishes itself from siblings by emphasizing grounded, evidence-based answers and refusal 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?

The description gives explicit when-to-use and when-not-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on' and 'prefer ask_pipeworx for casual lookups.' It also mentions the extra LLM call cost, helping the agent decide between the two similar tools.

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

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

The description discloses numerous behavioral traits beyond annotations: low-confidence short-circuit, closed market handling, wide spread warnings, cancellation rule parsing, and response shapes. Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds significant context without contradiction.

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

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

The description is well-structured with labeled sections (classifiers, fan-out examples, response shapes, safety notes) and front-loaded with the core purpose. However, it is verbose (≈400 words) and could be trimmed while retaining essential detail.

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

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

Given high complexity (multiple data sources, resolution logic, edge cases), the description covers all necessary aspects: input formats, classifier categories, fan-out examples, response structure, confidence handling, cancellation rules, and error states. It compensates for the lack of an output schema by detailing response shapes.

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

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

Input schema has 100% description coverage. The description adds context for 'depth' (quick vs thorough meaning), 'include_raw' (summary vs full payload), and 'market' (slug/URL/question text). It explains trade-offs and recommendations, such as 'default false (recommended)' for include_raw.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies inputs (slug, URL, question text) and deliverables (evidence packet + comparison). It differentiates from sibling tools by emphasizing the comprehensive one-call nature and category-specific data packs.

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

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

Explicit use cases are provided: 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. Examples illustrate when to use. However, it does not explicitly state when not to use or suggest sibling tools (e.g., polymarket_edges for simpler analysis).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by detailing what data is pulled (SEC EDGAR/XBRL for companies, FAERS for drugs), how fiscal years are handled, and that results are sorted by primary metric. No contradiction with annotations.

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

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

The description is a single paragraph but packs essential information efficiently, including usage examples, data sources, and behavioral notes. It is front-loaded with the primary action and uses bold for emphasis, though it could be broken into multiple sentences for readability.

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

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

For a tool with no output schema, the description adequately explains return format ('paired data + pipeworx:// citation URIs'). It covers input constraints (2–5 entities), data freshness, and sorting, making it fully self-contained and suitable for agent use.

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

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

Schema coverage is 100%, with both 'type' and 'values' documented. The description adds meaningful context beyond the schema, such as explaining that 'values' expects tickers/CIKs for companies and drug names for drugs, and provides examples (['AAPL','MSFT'], ['ozempic','mounjaro']).

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 side-by-side comparison of 2–5 companies or drugs, with example queries like 'X vs Y' and 'rank these companies', and explicitly distinguishes from sequential lookups. This provides a specific verb+resource and avoids ambiguity.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear guidance on when to use this tool instead of alternatives. It also lists exact phrasing triggers (e.g., 'which is bigger') that indicate appropriate 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?

Despite strong annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds substantial behavioral context: account/pricing requirements, the gaps[] mechanism, contradictions[] at certain depths, citation_uri always fetchable, semantic excerpting of large records, and latency expectations. No contradiction with annotations exists.

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

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

The description is long but every sentence carries critical information for a complex tool. It is front-loaded with the account requirement, then logically flows through functionality, use cases, depth specifics, output details, and latency. No fluff; density is justified by the tool's sophistication.

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

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

With no output schema, the description fully explains the findings packet (verbatim evidence, confidence, source, fetched_at, citation_uri), gaps[], contradictions[], hop field, and the limitation with current news. It also sets latency expectations and clarifies the structured-data-only scope, leaving little ambiguity 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 coverage is 100%, but the description enriches both parameters: for 'depth' it clarifies that 'standard' adds gap recovery and contradictions[], 'thorough' chases leads and needs a paid plan; for 'question' it notes 'Broad/multi-part is fine — decomposition is the point.' This goes well beyond the schema's bare definitions.

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

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

The description clearly states the tool's purpose: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources... in ONE call' and explains it decomposes questions into facets and routes them in parallel. It also explicitly distinguishes from open-web search and from sibling ask_pipeworx, making the tool's unique role unambiguous.

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

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

Provides explicit when-to-use and when-not-to-use guidance with alternatives: 'Best for broad/multi-part questions over structured data', 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx', and 'If you are not signed in, use ask_pipeworx instead'. This is exemplary usage direction.

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 and idempotent. Description adds value by specifying return format: 'top-N most relevant tools with names, descriptions, and full input schemas... no second schema lookup needed.' Does not contradict annotations.

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

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

Two sentences, each earning its place. First sentence defines purpose and scope, second explains output behavior and when to call. 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 adequately explains return format and that results are ready to call. Could mention edge cases like empty results or error handling, but not necessary for core completeness.

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

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

Schema coverage is 100% and description does not add significant semantic meaning beyond schema. It mentions aliases and limit defaults, but these are already in schema. 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?

Description clearly states 'Find tools by describing the data or task' and lists many domains, making the purpose highly specific. It distinguishes itself from sibling tools by being a meta-tool for discovering other tools.

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

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

Explicitly advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides clear context for when to use, though no explicit when-not conditions are given.

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

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

Beyond the read-only and idempotent annotations, the description discloses that the tool fans out across multiple sources (SEC EDGAR, XBRL, USPTO, news, GLEIF), details the specific data returned (filings with URIs, fundamentals sorted by period, patents with sunset note, news fallback, LEI), and mentions soft-fail behavior for patents. This adds significant behavioral context.

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

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

The description is well-structured, starting with common query examples and then detailing the tool's behavior. While it is informative, it is slightly verbose for a tool description; every sentence adds value, but some redundancy (e.g., repeated mention of patents sunset) could be trimmed for greater conciseness.

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 absence of an output schema, the description comprehensively explains what the tool returns: CIK, company name, recent filings with deep links, fundamentals, patents (with caveat), news via GDELT/GNews fallback, and LEI. It also covers limitations (only US companies, no names) and provides fallback instructions, making it fully informative.

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 already describes the parameters (type and value), but the description adds crucial context: 'type' is currently limited to 'company', and 'value' accepts ticker or zero-padded CIK. It explicitly states that names are not supported and provides examples (AAPL, 0000320193), enhancing understanding beyond the schema.

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

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

The description clearly states the tool's purpose: to provide a full cross-source profile of a US public company. It uses specific verbs like 'tell me about', 'research', 'brief me on', and explicitly distinguishes itself from chaining single-pack lookups, making its purpose unambiguous.

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

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

The description explicitly advises to prefer this tool over single-pack SEC/XBRL/news lookups for holistic views. It also clarifies that names are not supported and recommends using 'resolve_entity' first if only a name is available, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds no additional behavioral information such as data freshness, response limits, or latency, failing to add value beyond the structured fields.

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

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

The description is very concise (4 words), but excessive brevity sacrifices clarity. It could easily include a phrase like 'weather forecast' without losing conciseness.

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 an output schema and annotations, the description remains incomplete. It does not specify the forecast type, default units, time range handling, or any coordinate restrictions, which are necessary for a 7-parameter 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 only 43% schema description coverage, the description must compensate for missing parameter details, but it does not. It omits explanations for parameters like 'lat', 'lon', 'lang', and 'exclude', leaving agents uncertain about their meaning.

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

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

The description 'Full forecast at point' is vague and fails to specify what type of forecast (e.g., weather, financial). It does not distinguish itself from sibling tool 'forecast_grid' or provide any scope or resource context.

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

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

No guidance provided on when to use this tool versus alternatives like 'forecast_grid', nor any prerequisites or constraints such as valid coordinate ranges or time formats.

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, so the description is not required to repeat these. However, the description adds no additional behavioral context beyond annotations, resulting in a baseline score.

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 short but not necessarily concise in conveying meaning. It is a single phrase with no structure or prioritization of key information.

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

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

Despite having an output schema and multiple parameters, the description lacks essential context about return values, grid resolution, or usage scenarios. It is incomplete for effective tool selection.

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 0%. The description does not explain the meaning of lat, lon, time, or units. The examples provide clues but the description itself offers no semantic context.

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 'GFS/ECMWF grid forecast' identifies the data source but lacks a verb and does not differentiate from the sibling 'forecast' tool. It is vague about what action the tool performs.

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

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

No guidance is provided on when to use this tool versus alternatives like 'forecast'. There are no prerequisites or exclusions mentioned.

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 idempotentHint=true, which are consistent with the description's 'Delete' operation. The description adds useful context about when to delete (stale context, done tasks, sensitive data) 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 two sentences, front-loaded with purpose, and includes usage guidance without wasted words. Every sentence adds value.

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

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

The tool has one required parameter and no output schema. The description explains purpose, usage, and pairing, which is adequate for a simple delete operation. It does not mention error behavior (e.g., if key not found), but that is not critical for basic 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 the parameter 'key' is described as 'Memory key to delete' in the schema. The tool description repeats this without adding extra semantics, so it meets the baseline for full schema coverage.

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

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

The description clearly states the verb 'Delete' and the resource 'a previously stored memory by key'. It also distinguishes itself from sibling tools by explicitly mentioning 'Pair with remember and recall', indicating complementary operations.

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

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

The description provides explicit use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with alternatives 'remember and recall', but does not explicitly state when not to use the tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it fetches the page, extracts content, and emits standard markdown format, which provides useful behavioral context beyond annotations. No contradiction found.

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

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

The description is concise with 3-4 sentences, each serving a clear purpose: purpose, process, output, use cases. No wasted words, and 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 low complexity (2 parameters, full schema coverage, annotations present, no output schema), the description fully covers what the tool does, how it works, and what it returns. It explicitly states the output format, which compensates for the lack of output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant new meaning beyond the schema; it rephrases the URL parameter and only indirectly mentions max_links through the extraction description.

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

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

The description clearly states 'Generate a production-ready llms.txt file for any URL' with specific verb and resource, and distinguishes from siblings by listing explicit use cases like auditing competitor AI presence. There is no ambiguity.

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 three concrete use cases ('getting a client's site indexed', 'drafting for your own project', 'auditing competitor'), providing clear context. However, it does not specify when to avoid using this tool or compare to alternatives like scan_competitor_ai_presence.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds value by listing output fields (id, type, params, created_at, last_fired_at, fire_count). No contradictions. Could mention pagination, but not required for simple list.

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

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

Two concise sentences: first states purpose and output fields, second gives usage guidance. 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?

For a simple tool with one optional parameter and no output schema, the description fully covers what agents need: what it returns, when to use it. 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% for the single parameter (include_inactive). Description does not add extra meaning beyond schema, which is adequate. Baseline of 3 appropriate.

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

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

Clearly states 'List the caller's active subscriptions' with specific verb and resource. Differentiated from siblings 'subscribe' and 'unsubscribe' by implying it's for reviewing, not modifying.

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: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Tells when to use and implies alternatives (subscribe/unsubscribe).

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

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

Annotations only state low-level hints, so the description carries the burden. It discloses rate limiting (5 per identifier per day), the free/no-quota nature, the claim_token workflow for later retrieval, and the constraint that only Pipeworx tools are in scope. No contradictions exist between this and 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 longer than typical, but nearly every sentence adds necessary operational detail (use cases, scope exclusion, token workflow, rate limit). It is front-loaded with the core action and organized logically, though it could be tightened slightly without losing value.

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

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

Given there is no output schema, the description sufficiently explains what the tool returns (a claim_token when filing without an account, and status/changes when checking a token). It also covers routing restrictions, privacy (don't paste user prompt), and operational expectations, making it complete for this complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful practical context beyond the schema: instructs not to paste the end-user prompt, explains how to use claim_token for follow-up, and clarifies issue framing relative to Pipeworx tools/packs. This is useful but not exhaustive for every nested context field.

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 verb (Tell the Pipeworx team) and resource (Pipeworx feedback) while defining concrete use cases like bug, feature, data_gap, and praise. It distinguishes this from sibling tools such as ask_pipeworx by emphasizing this is specifically for reporting issues with Pipeworx-served 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?

Explicit guidance is given on when to use the tool ('Use when a tool returns wrong/stale data...'), and it explicitly directs users away from using it for tools from other MCP servers ('file it with that server instead'). It also clarifies scope, message requirements, and claim_token usage, making selection unambiguous.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false), description adds valuable context: data source (CF analytics-engine), no PII, caching behavior (5min-1h depending on window), and self-aggregating nature. 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 four sentences, front-loaded with output and key uses, followed by technical details. No redundant or unnecessary information.

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

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

Given the tool's simplicity (one optional param, no output schema), description fully covers output (top tools, packs, volume), behavior (caching, data source, privacy), and use cases. No missing context for an agent to decide to invoke it.

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

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

Schema description coverage is 100% with the window parameter already well-described (enum, default, behavior). Tool description doesn't add new parameter details beyond mentioning the window, so baseline 3 applies.

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

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

Description clearly states the tool returns 'top tools, top packs, and total call volume' over a specified window, with specific use cases listed. It distinguishes itself from sibling tools like 'discover_tools' by focusing on trending data derived from other AI agents.

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 three explicit use cases (discovering hot data sources, confirming canonical choices, aligning use cases). However, it does not explicitly mention when not to use this tool or compare it directly to alternatives among the many siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description goes far beyond by detailing the scan process, similarity thresholds, partition filters, and fill check against live CLOB depth. It explicitly warns when a trade should not be executed, adding critical behavioral context.

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

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

The description is well-structured with clear sections for each mode and special notes (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). However, it is somewhat verbose; could be tightened without losing meaning. Still, the front-loaded purpose statement and logical flow earn a 4.

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 thoroughly explains the response structure (opportunities[], partition_check, fill check details) and edge cases (low similarity, placeholder filtering, book depth). It provides a complete picture for an agent to understand 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?

Schema coverage is 100%, but the description adds substantial meaning: for 'event' it explains how to use slugs and URLs, for 'topic' it describes cross-event scanning, Jaccard similarity, and placeholder filtering. The description provides context and examples that make the parameters far more actionable than 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 explicitly states the tool finds arbitrage opportunities via monotonicity violations + partition-sum checks, and distinguishes between three modes (no args, event, topic). It provides specific examples for each mode, making the purpose extremely clear and different from sibling tools.

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

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

The description gives explicit guidance on when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. It also points to an alternative tool (polymarket_fill_risk) for custom sizing, covering when not to use this tool.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description does not contradict them. It goes far beyond annotations by detailing the three model families, edge metrics, caching at KV level (1h), diagnostic diagnostics, and tradeable-edge knobs, providing rich behavioral context.

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

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

The description is long but front-loaded with purpose and usage. Every sentence adds detail; however, it could be slightly more consolidated without losing meaning. Still appropriate for a complex tool.

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

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

Given the tool's complexity (9 parameters, no output schema, three segments), the description covers purpose, models, edge metrics, knobs, response structure, diagnostics, caching, and limitations (Fed bets). It provides complete guidance for an agent to use the tool 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 all 9 parameters are already documented in the schema. The description adds value by explaining how parameters interact (e.g., 'Tradeable-edge filter' for max_spread_pp and min_liquidity) and when to adjust them (e.g., 'Bump for very thin partitions'). This extra context raises it above the baseline.

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

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

The description starts with a clear verb-resource pair: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It distinguishes from siblings like polymarket_arbitrage by focusing on Pipeworx's proprietary data disagreement.

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

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

The description explicitly states the intended use case: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It explains category filters and knobs but does not mention when to avoid this tool or how it compares to alternatives like polymarket_edge_tracker.

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 tool is annotated as readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: snapshots are written on cache-miss (so gaps in data mean no one scanned that day), history is bounded by a 60-day TTL, and decay numbers are based on daily closes (net of default slippage). This goes well beyond the annotations and fully discloses relevant behaviors.

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 comprehensive but well-structured: it starts with the core purpose, then explains each response field in detail, and ends with limits. Every sentence adds value, though it could be slightly more concise. Overall, it's appropriately sized for the complexity of the tool.

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

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

Given that there is no output schema, the description fully describes the response structure: tracked[], expired[], snapshot_dates[], and explains each field (first_seen, trend, decay_pp_per_day, lifespan_days, etc.). It also covers limits and data gaps. For a tool with two simple parameters, this is exceptionally complete and leaves no ambiguity.

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 already describes both parameters with 100% coverage. The description adds meaning by stating the default and valid range for 'days' (default 14, max 30) and the default for 'window' ('1wk'). This provides useful context beyond the schema, justifying a score above 3.

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

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

The title and first sentence clearly state that this tool provides edge persistence and decay telemetry from daily snapshots. It answers 'how long has this edge existed and is it shrinking?', which is specific and distinct from sibling tools like polymarket_edges (current snapshot) or polymarket_arbitrage (arbitrage opportunities). The description goes into detail about the response fields, further clarifying 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?

The description provides context for when to use this tool: when you need to distinguish between a fresh wide edge and an old one (the latter is wide for a reason nobody is willing to take). It also explains limits like the 60-day snapshot TTL and that decay numbers are from daily closes, not intraday. It does not explicitly say when not to use this tool or name alternatives, but the sibling context and description imply it's for historical analysis vs. current edges.

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: it walks the ladder, returns specific fields like slippage_pp and verdict, and for basket mode details per-leg fill, thin_legs, and forced directional risk. This fully discloses operational traits.

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 bold section headers for modes and explicit parameter explanations. While somewhat lengthy, every sentence adds value and critical details, and the core purpose is front-loaded. A minor trim could be possible, but it remains clear and efficient.

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

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

Despite no output schema, the description fully enumerates return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, etc. for single; theoretical_sum, realizable_sum, capture_ratio, profit_usd, thin_legs, etc. for basket). It also covers usage prerequisites ('REQUIRES one of market or event') and warns about key risks. Complete given 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%, but the description adds rich semantics: explains each parameter's role in both modes, default values (size_usd=1000), and how size_usd is interpreted for buys vs sells and for basket mode. 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 starts with a clear, specific verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It then distinguishes two distinct modes (single-market and basket) with different behaviors and outputs, making the purpose unmistakable.

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

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

The description explicitly states when to use this tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why (theoretical overround not capturable on thin books, partial fills create directional risk), providing clear context and exclusions.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds extensive behavioral context: SAFETY FIELDS explaining compatibility warnings, temporal alignment checks, and counters for skipped leg-pair comparisons. 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 relatively long but well-structured with clear headings (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence adds value, though some elaboration could be tightened. Still efficient for the complexity.

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

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

Despite lacking an output schema, the description comprehensively details the response structure (leg-by-leg prices, matched spread, safety fields). It covers edge cases (compatibility warnings, temporal misalignment), making the tool's behavior fully predictable.

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% (all 3 parameters described). The description adds value by explaining the two modes (topic vs. explicit), providing example values, and clarifying override behavior. Slight redundancy with schema but adds usage context.

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 that the tool computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It uses specific verbs ('compute', 'auto-fetch') and distinguishes itself from sibling tools like 'polymarket_arbitrage' by focusing on cross-venue 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?

The description explicitly outlines two usage modes ('topic' and explicit tickers) and provides guidance on when to expect results vs. when not (e.g., compatibility warnings). It warns that pre-mapped topics often return warnings, setting proper expectations for the agent.

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, and destructiveHint false. Description adds scoping detail (by identifier) and pairing info, complementing annotations without contradiction.

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

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

Two sentences, front-loaded with purpose, no redundant words. Efficient and clear.

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

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

Without output schema, description explains return values (value or list of keys) and scoping. While sufficient, it could briefly mention response format (e.g., JSON structure) for completeness.

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

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

Schema coverage is 100% with description for the key parameter. Tool description adds value by explaining behavior when key is omitted (list all keys), which is not explicit in 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?

Description clearly states verb ('retrieve' or 'list') and resource ('saved values/keys'), and distinguishes from siblings 'remember' and 'forget'. Includes examples for both cases.

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 context: 'look up context the agent stored earlier' and mentions pairing with remember/forget. However, lacks explicit when-not-to-use or comparison to other sibling tools like search.

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

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

Annotations declare readOnlyHint=true, but the description introduces the mark_read parameter which modifies read state, contradicting the read-only hint. No other behavioral traits (rate limits, auth needs) are disclosed 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 a single paragraph that front-loads the main purpose and includes necessary details without being overly verbose. Minor improvement possible with clearer structure.

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

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

No output schema exists, so the description's mention of return fields (source, citation_uri, raw payload) is helpful. However, the contradiction with annotations undermines completeness, and there is no guidance on error handling or performance.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value with examples (e.g., 'sec_8k') and clarifies the effect of mark_read, which goes beyond 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 pulls fired events from the subscription feed. It specifies the resource (fired events) and action (pull), and distinguishes it from sibling tools like list_subscriptions by focusing on reading events rather than managing subscriptions.

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

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

The description provides clear context: suitable for polling, alternative endpoint for scripts. It explains the mark_read feature but does not explicitly exclude scenarios where siblings are preferable, though this is implied.

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

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

Annotations indicate readOnly, idempotent, non-destructive, and open world. The description adds detailed behavioral traits: fan-out to multiple sources, GDELT→GNews fallback on rate-limit/5xx, USPTO soft-fail, and the return format (changes[] grouped by source + total_changes + citation URIs). 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 a single, well-structured paragraph that front-loads example queries. Every sentence contributes unique information without redundancy. It is efficient and actionable.

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 three parameters and no output schema, the description fully covers tool behavior: sources, fallback, return structure, since format, and limitations. It also provides a sibling comparison, making it contextually 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%, so baseline is 3. The description adds meaningful extra guidance: explains ticker/CIK for value, recommends '30d' or '1m' for since, and clarifies only 'company' type supported. This goes beyond the schema's own 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 defines the tool as providing a change feed for a company over a recent window, listing specific sources (SEC, GDELT/GNews, USPTO) and contrasting with sibling entity_profile. The examples upfront make the purpose immediately 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?

The description begins with explicit query examples ('What's new with X', etc.) and directly tells when to use entity_profile instead. It also recommends typical since values ('30d' or '1m'), providing clear usage guidance.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. Description adds important context about persistence (authenticated vs anonymous, 24-hour retention) and that data is scoped by identifier, going 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?

Three sentences with no filler. Each sentence conveys essential information: purpose, usage timing, and behavioral 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?

Despite no output schema, the description fully covers what the tool does, when to use, and how the data is stored. No gaps given the tool's simplicity.

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

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

Input schema has 100% coverage with clear descriptions for both key and value. Description includes example values but adds limited extra meaning beyond the schema, meeting the baseline.

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

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

Description clearly states 'Save data the agent will need to reuse later' and provides examples (resolved ticker, target address, user preference). It distinguishes itself from sibling tools like recall and forget by explicitly mentioning them.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and advises to pair with recall and forget. Also clarifies authentication scope and retention duration.

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 (read-only, idempotent, open-world), the description discloses behavioral details such as graceful degradation when GLEIF/OpenFIGI is unavailable, the cascading through multiple lookup endpoints, and the explicit representation of unresolved identifiers under `unresolved`. These are valuable additions to what annotations already convey.

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

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

The description is longer than average but well-structured and front-loaded with query examples. Each section contributes useful information about supported types, resolution behavior, and degradation. It could be tightened slightly, but the length is justified for 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?

Despite lacking an output schema, the description thoroughly details expected outputs for both entity types (CIK, ticker, company_name, LEI, ownership, FIGI, RxCUI, ingredient, brand) and covers source attribution, unresolved handling, and failure behavior. For a two-parameter tool, this is exceptionally 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%, giving a baseline of 3, but the description adds meaningful nuance by indicating the value parameter can accept natural-language user-spoken names (e.g., 'What's the ticker for...') rather than only tidy identifiers. This extends beyond the schema's examples of 'AAPL' or '0000320193'.

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

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

The description opens with concrete query examples and explicitly states 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It distinguishes itself from sibling tools by focusing on identifier resolution, with the directive 'Use FIRST whenever you have a name but need an ID' further clarifying its unique role.

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 an explicit when-to-use rule: 'Use FIRST whenever you have a name but need an ID.' It also notes that the tool replaces 2-3 manual lookups, providing context for its use. However, it does not explicitly state when not to use it or mention alternative tools, so it falls just short of a 5.

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

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

Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds that each entity is probed with ai_visibility_check, results are ranked, and the output includes score, confidence, and signal density. No contradictions with annotations.

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

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

The description is three sentences long, each serving a purpose: first explains the core comparison and ranking, second gives use case example, third specifies output details. 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 the tool has no output schema, the description adequately describes the ranked list (score, confidence, signal density). It mentions the dependency on ai_visibility_check. However, it could mention error handling or limits (2-8 entities), though the schema specifies that. Minor gap.

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

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

Schema description coverage is 100%, but the description adds crucial context: first entity is treated as the 'subject' for narrative, the models parameter lists supported models and API key requirements, and the context parameter disambiguates common names. This goes 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 it compares AI visibility across entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It distinguishes from the sibling tool 'ai_visibility_check' which targets a single entity, and 'compare_entities' which is more general.

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

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

It explicitly says 'Useful for competitive AI-marketing audits' and provides an example question ('does Claude know about us as well as our competitors?'). While it does not state when not to use, the context makes it clear it is for multi-entity comparison, differentiating it from single-probe tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral details: composite fan-out to multiple services, partial failure degradation, bundlephobia's 5-30s first measurement, and that sources_failed lists timeouts. 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 well-structured, starting with the core functionality, then usage, return structure, and caveats. Every sentence provides essential information without redundancy. It is appropriately sized for the complexity of the tool.

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

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

With no output schema, the description fully explains the return format (summary block fields, per-advisory detail, links, recent versions) and error behavior. It also covers ecosystem scope and fallback alternatives, making it complete for a tool of this complexity.

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

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

Schema coverage is 100% with clear parameter descriptions. The description does not add significant meaning beyond the schema, only implying defaults and scoped packages, which are already covered. 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 composite check for deciding whether to add an npm package, covering license, advisories, bundle size, and tree-shake support. It distinguishes itself from sibling tools by focusing on npm dependency scanning, explicitly noting the ecosystem limitation and alternatives.

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 usage guidance with example queries and states when to use (e.g., 'is X safe / popular / small') and when not to use (other ecosystems like PyPI, Maven, etc.), including direct 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 safety (readOnly, idempotent, non-destructive). Description adds details about truncation at 200K chars with flag, embedding model (BGE-base-en), window size (500-char overlapping), and cosine similarity, going well 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?

Description is two well-structured sentences that front-load the core action. While packed with details, every sentence serves a purpose; slight room for tighter phrasing but no waste.

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

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

Given only 3 parameters and no output schema, description explains return format (passages with offsets and similarity scores), constraints (200K chars truncation), and embedding details, providing sufficient context for an agent to use the tool 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 coverage is 100%, so baseline is 3. Description adds value by specifying the 200K char limit for 'text', default of 5 for 'limit', and providing natural-language query examples for 'query', 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 it performs semantic search inside a fetched record, specifies the use case (records too large for prompt), and differentiates from sibling tools like ask_pipeworx_grounded.

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

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

Explicitly says when to use ('when the record is too big to cram into the prompt') and suggests an alternative workflow ('Pairs with ask_pipeworx_grounded'), providing 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds significant behavioral context: it returns a subscription id, requires persistence-supporting account type, details delivery constraints (SMS verification, 10/day cap, webhook signing and auto-disable), and all types with parameter examples. No contradiction with annotations.

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

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

The description is well-structured with front-loaded purpose and return value. It uses bullet-like formatting for types and delivery channels, making it scannable. While detailed, every sentence adds necessary information—prerequisites, type examples, delivery constraints. Slightly long but justified given 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 (3 parameters, 2 required, nested objects, 5 enum options, no output schema), the description covers all necessary aspects: purpose, prerequisites, type-specific parameters, delivery channels with constraints, and return value (subscription id). It also mentions the always-on feed, which is important context. The description is fully adequate for an agent to correctly invoke the tool.

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

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

Schema description coverage is 100%, but the description adds substantial meaning beyond the schema: it provides concrete examples for each type, explains the required 'sponsor' or 'condition' for clinical_trial, details delivery channel constraints including SMS verification and webhook HMAC signing, and mentions the one-time webhook_secret. This greatly enriches the schema's minimal 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 verb (Create), the resource (proactive monitoring subscription to a live-data event stream), and the outcome (returns the new subscription id). It distinguishes itself from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation of a persistent subscription.

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

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

The description explains when to use the tool (to create a monitoring subscription) and specifies prerequisites (Pipeworx OAuth account, anonymous/BYO cannot persist). It provides examples for each subscription type but does not explicitly contrast with alternatives like recent_alerts for pulling events, though the context is clear.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable behavioral context: it returns category-bucketed example questions with tool+argument shapes from a live catalog, and that it serves as an onboarding entry point.

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

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

The description is somewhat verbose with repeated phrases and a long list of categories. While structured, it could be more concise without losing clarity.

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

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

Despite lacking an output schema, the description thoroughly explains the return content: category-bucketed examples with tool+argument shapes. It covers the no-argument and topic-argument cases, and mentions the live catalog source.

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

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

Schema coverage is 100%. The description adds meaning beyond the schema by explaining the effect of omitting the topic (full spread) versus providing a focus area, and lists example values for topic.

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 an onboarding entry point that returns example questions categorized by topic, with exact tool+argument shapes. It distinguishes itself from siblings like ask_pipeworx and discover_tools by being specifically for initial exploration and idea generation.

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

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

The description explicitly advises using this tool first when the user does not know what Pipeworx can do, and explains how to omit or provide the topic parameter. It lacks explicit guidance on when not to use it, but the priority is clear.

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

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

The description adds valuable behavioral context beyond the annotations: ownership enforcement, row deactivation (not deletion), and preservation of historical events. This aligns with the annotations (destructiveHint=false, idempotentHint=true) and provides clear expectations.

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

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

Three sentences, front-loaded with the main action, no redundant information. Every sentence adds value and the description is compact.

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

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

For a single-parameter, straightforward tool, the description covers purpose, constraints, side effects, and relationship to other tools (recent_alerts). No output schema is needed, and the description 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?

The schema has 100% coverage with a description for the 'id' parameter. The tool description does not add further details about the parameter beyond what the schema provides, 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?

The description clearly states 'Cancel a subscription by id.' This is a specific verb-resource combination that distinguishes it from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

It explicitly mentions ownership enforcement ('you can only cancel your own subscriptions'), which guides when to use this tool. It also links to recent_alerts for historical events, but does not explicitly state when not to use it or provide alternatives.

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

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

Beyond the annotations, the description richly explains the verdict set, and crucially clarifies that could_not_verify means the check did not happen and is not evidence, while unsupported means no source covers the claim. This distinction is vital for correct use and is not inferable from annotations or schema.

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

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

The description is long but every sentence earns its place, starting with natural-language triggers, then the use case, routing logic, return values, error semantics, and a summary of its aggregation benefit. The 'IMPORTANT' section isolates the most critical caveat for callers.

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

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

With no output schema, the description fully specifies the verdict enum and the special error payload, distinguishing could_not_verify from unsupported. It explains both routing paths and the fast-path math, giving an agent everything needed to call and interpret results confidently.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds valuable guidance on tolerance_pct, including that it overrides the tolerance implied by the claim wording and that 1–2 is suitable for hallucination detection, which goes beyond the schema's basic type description.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with a specific structured fast path for company financials and a grounded pipeline for all other claims. It distinguishes itself by noting it replaces 4–6 sequential calls, making its role among siblings 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?

It explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct,' and explains the routing logic between SEC EDGAR/XBRL and the generic grounded pipeline. It does not explicitly name sibling tools or provide when-not conditions, but the broad 'all factual claims' scope makes exclusions largely unnecessary.

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