Disney

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

Annotations already declare readOnlyHint=true and idempotentHint=true; description adds cost implications (free default vs BYO key for Anthropic), return format, and default model, providing useful 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?

Three focused sentences with front-loaded main action, no redundant words, and each sentence serves a distinct informative purpose.

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

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

Despite lacking an output schema, description specifies return structure (per-model {score, confidence, signals, raw_response} + combined view) and covers use cases, parameters, and cost rules, making it fully informative for its 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 has 100% description coverage, baseline 3. Description adds value by explaining _apiKey as 'BYO key — you pay Anthropic directly' and context as 'Helps disambiguate common names', surpassing schema details.

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

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

The description uses specific verbs ('Probe') and resources ('LLMs for what they know about a business/brand/product/topic and score visibility'), clearly distinguishing it from siblings like 'scan_competitor_ai_presence' by emphasizing multi-model probing with scoring.

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

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

Explicitly lists use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains when to use the optional Anthropic model (requires _apiKey), 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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavior beyond that: it 'fills arguments', returns structured answers with citation URIs, works on every tier, and makes one fast call. 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 longer than typical but front-loaded with 'PREFER OVER WEB SEARCH' and each subsequent section earns its place: scope, routing behavior, trigger phrases, examples, and alternatives. While slightly verbose, the structure is logical and not repetitive.

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

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

Given the tool's complexity and lack of output schema, the description fully explains return value ('structured answer with stable pipeworx:// citation URIs'), the breadth of coverage (SEC, FDA, FRED, etc.), and escalation paths. It leaves no major gap for an agent deciding to invoke this tool.

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

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

Schema coverage is 100% with all parameters as aliases for 'question.' The description adds semantic value by providing trigger phrases and concrete examples of acceptable questions, guiding the agent on what to pass. This goes beyond the schema's basic field 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 states a specific verb+resource: it 'routes the question to the right one of 5,497 tools across 1439 verified sources' and 'returns the structured answer with stable pipeworx:// citation URIs.' It clearly distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by positioning as the default entry point.

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

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

Provides explicit when-to-use guidance: 'PREFER OVER WEB SEARCH', 'Use whenever the user asks...', 'START HERE for most questions.' It also gives when-not-to-use alternatives: 'Step up only when needed' for ask_pipeworx_grounded and deep_research, and covers breaking-news routing.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds that it's a beta with candidate routing enabled live whenever under test, that no candidate is active now (so it matches ask_pipeworx), and that it falls back to nothing—it's a full working router. This adds context beyond the annotations about its experimental nature and current state.

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

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

The description is moderately concise, with four sentences that each contribute useful information: beta identity, current state, usage guidance, and assurance it's fully functional. It could be tighter but is not wasteful.

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

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

The tool is a complex universal router, and the description covers its experimental nature, current equivalence to ask_pipeworx, usage, and response shape. It proactively clarifies that there is no fallback, which is important for an agent evaluating whether to use it. Without an output schema, the description's mention of 'same response shape' as ask_pipeworx provides sufficient context.

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

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

The schema already has 100% description coverage for all six parameters (question and five aliases). The description mentions 'same arguments' as ask_pipeworx but doesn't add specific parameter details, which is acceptable since the schema covers them. 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 this is a beta version of ask_pipeworx, an identical universal router with the same 5,497 tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx by being the experimental edge for candidate routing improvements.

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 to use it exactly like ask_pipeworx when you want the newest routing, and notes results are compared against the stable router. It also clarifies that currently no candidate is active, so it matches ask_pipeworx exactly, which helps decide when to use it. It doesn't explicitly list exclusions, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes further by detailing the return structure (answer, evidence, confidence, etc.), the exact refusal reasons, the internal pipeline ('routing... fetches the data'), and the extra LLM call cost, providing deep behavioral transparency 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 dense but well-structured, front-loading the core purpose and then adding usage guidance and return details. Every sentence contributes useful information, though it is slightly longer than necessary for a simple one-parameter 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?

Even though there is no output schema, the description fully defines the success and failure return shapes with specific refusal reasons. It also provides context on when to use the tool versus casual lookups, making it complete for an agent to invoke correctly.

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

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

All six parameters are aliases for the same 'question' input, and the schema already covers 100% of them with descriptions and alias notes. The description does not add extra parameter semantics, but since schema coverage is complete, the baseline score of 3 is appropriate.

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

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

The description opens with 'Hallucination-resistant answer mode for high-stakes reads,' which clearly defines the tool's specific purpose and scope. It also distinguishes itself from the sibling ask_pipeworx by explaining that it extracts answers strictly from tool results and returns explicit refusals when data doesn't support an answer.

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

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

Provides explicit guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and 'prefer ask_pipeworx for casual lookups.' It also mentions the additional cost tradeoff, helping the agent choose appropriately between alternatives.

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

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

The description goes far beyond annotations by detailing fan-out logic, response shapes, resolver contract, parent event extraction, news fallback, safety mechanisms, cancellation rules, and more. 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 comprehensive but very long and lacks sectioning. The first sentence front-loads the purpose, but the density of detail could be structured better for quicker parsing. Every sentence adds value, but conciseness is compromised.

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 (classifiers, fan-outs, edge cases), the description covers all critical aspects including resolver confidence, parent events, news fallback, and safety guards. No output schema exists, but response shapes are thoroughly explained.

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

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

Schema coverage is 100%, and the description adds significant value: explains market input formats (slug, URL, question text), depth levels with defaults, and the impact of include_raw on response size. This far exceeds baseline expectations.

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

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

The description clearly states 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies multiple input formats and detailed behavior, making the tool's purpose unmistakable despite not explicitly distinguishing from siblings.

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

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

The description explicitly states use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. It provides extensive context on how to use the tool but does not mention when not to use it or list alternative 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 readOnly, openWorld, idempotent, non-destructive. Description adds substantive detail: data sources (SEC EDGAR for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. No contradiction with annotations.

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

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

Description is a single paragraph but front-loads the core purpose. Contains example queries and all key details without redundancy. Could be slightly more structured but efficient overall.

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

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

Given no output schema, description explains return format: 'paired data + pipeworx:// citation URIs per entity'. Covers both entity types, sorting behavior, and parallel call efficiency. Complete for the tool's complexity.

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

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

Schema coverage is 100% with descriptions for type and values. Description adds meaning beyond schema: explains that values are tickers/CIKs for company and names for drug, includes examples and constraints (2-5 items). Valuable context not in schema.

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

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

Description states specific verb+resource: 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call'. Clearly distinguishes from sibling tools like entity_profile (single entity) and scan_competitor_ai_presence (different purpose).

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

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

Explicitly advises 'ALWAYS PREFER over sequential single-pack lookups when comparing entities'. Provides example queries showing when to use. Lacks explicit exclusions, but context is strong.

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 (readOnly, openWorld, etc.), the description adds rich behavioral context: account requirements, parallel decomposition across 5,497 tools, the gaps[] and contradictions[] fields, the never-invented guarantee, resolvable citation URIs, semantic excerpting, and expected latency. It also states limitations for current-news topics. No contradiction with annotations.

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

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

The description is long but densely packed; each sentence covers a distinct aspect (auth, alternatives, scope, output, depth semantics, timing) without fluff. It front-loads account requirements and alternatives, though could be slightly tighter for a tool with such clear schema support.

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

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

Despite no output schema, the description explains the return packet in detail: findings with evidence/confidence/source/fetched_at, gaps[], contradictions[], hop field, and citation_uri. It covers prerequisites, edge cases (news topics return empty gaps), and performance, making it sufficient for agent selection and invocation.

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

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

Schema coverage is 100% and the schema already provides detailed descriptions for both parameters, especially depth's enum values. The tool description adds incremental context (e.g., standard 're-angles unanswered gaps', thorough 'chases leads') that clarifies real-world impact, but the schema does most of the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs and resources: 'Grounded multi-source research across Pipeworx's 1439 STRUCTURED data sources' in ONE call. It explicitly distinguishes itself from open-web search and from siblings like ask_pipeworx, making the unique scope 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 provides explicit when-to-use vs alternatives: 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS topics, prefer ask_pipeworx', and 'If you are not signed in, use ask_pipeworx instead'. It also notes depth:'thorough' requires a paid plan, giving clear conditional guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context about return content (top-N tools with full schemas and curated examples, ready to call) and 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: purpose first, then examples, then benefits, then usage advice. It is slightly long but each sentence adds value, achieving a good balance.

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

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

Despite no output schema, the description fully explains what is returned (top-N tools with names, descriptions, schemas). This is complete for the tool's purpose and complements the rich annotations.

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

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

Schema coverage is 100% with all parameters described. The description adds meaning by explaining that 'query' is a natural language description and lists aliases, plus provides examples. 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 'Find tools by describing the data or task' and provides extensive examples of use cases (SEC filings, FDA drugs, etc.), making the purpose unmistakable. It differentiates itself from sibling tools by being a meta-tool for discovery.

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 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear when-to-use guidance and implies when not to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing the multi-source fan-out (SEC, XBRL, USPTO, news, GLEIF) and specific return fields, plus a soft-fail note on patents. 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 cohesive paragraph, front-loaded with example queries, but packs a lot of detail. It could be slightly more structured (e.g., list format), but remains clear and efficient with minimal 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?

Despite no output schema, the description comprehensively explains return fields (cik, filings with URIs, fundamentals, patents with expiry, news, LEI) and limitations. It covers what an agent needs to know for holistic entity profiles.

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 both parameters. The description enriches this by explaining that 'type' only supports 'company' and 'value' must be ticker or zero-padded CIK, not names, and directs to resolve_entity for name resolution—adding meaning beyond the schema.

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

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

The description clearly states the tool provides a full cross-source profile of US public companies in one parallel call, using examples like 'Tell me about X' and 'company profile for Microsoft'. It distinguishes itself from siblings by explicitly recommending it over chaining single-pack lookups and referencing resolve_entity for name resolution.

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 (holistic view of a US public company) and when not to use (only ticker or CIK, not names; names require resolve_entity first). It contrasts with chaining single source lookups, 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 already indicate destructive and idempotent behavior. The description adds minor context about clearing sensitive data, but does not significantly enhance 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, each purposeful. No redundancy. Front-loaded with key action.

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

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

Given the tool's simplicity (single parameter, no output schema), the description covers purpose, use cases, and related tools sufficiently.

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

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

Schema coverage is 100%, so the schema fully documents the parameter. The description does not add additional meaning beyond the schema definition.

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 deletes a memory by key, using a specific verb and resource. It distinguishes itself from sibling tools like 'remember' and 'recall' by indicating it is the deletion counterpart.

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

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

Provides explicit guidance on when to use (stale context, task done, clearing sensitive data) and pairs with related tools, offering clear context for tool selection.

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

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

Annotations include readOnlyHint=true, idempotentHint=true, etc. The description adds behavioral context: fetches page, extracts title/description/key links, emits standard markdown. 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?

Three sentences: first states purpose, second explains process and output, third lists use cases. No wasted words, front-loaded with key info.

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 low complexity (2 params, no output schema), the description covers all necessary aspects: input, process, output format, and use cases. Sufficient for agent invocation.

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

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

Schema coverage is 100% with clear descriptions. The description adds examples for URL (e.g., 'https://example.com') and default/max for max_links, providing extra value beyond the schema.

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

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

The description clearly states the tool generates a production-ready llms.txt file for a given URL, specifying the verb 'generate', the resource 'llms.txt file', and details about extraction and output format. It distinguishes itself from sibling tools by focusing on AI indexing 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 use cases: getting a client's site indexed, drafting for own project, auditing competitor. It does not mention when not to use or alternatives, but the context is clear enough for agents to decide.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds value by specifying the return fields ('full record: films, short films...'), providing context beyond the annotations. 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?

Two sentences, verb-first, no filler. Every word earns its place. The structure is front-loaded and efficient.

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

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

For a simple fetch-by-id tool with one parameter, full schema coverage, and rich annotations, the description completely covers input (id) and output (full record with listed fields). No gaps remain.

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

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

Schema coverage is 100% and the parameter 'id' is well-described with an example. The description reinforces 'by numeric id' but does not add significant new detail beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Fetch') and resource ('Disney character') and clarifies the unique key ('numeric id'). It distinguishes from sibling tools like list_characters and search_characters by focusing on single record retrieval by id.

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

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

The description clearly indicates when to use (when you have a numeric id), but does not explicitly state when not to use (e.g., if you don't have the id, prefer search_characters). This is adequate for a simple lookup tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds return format details but no additional behavioral traits (e.g., pagination limits, caching).

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, second explains return structure and use case. No unnecessary words.

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

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

Given thorough annotations and complete schema, the description adequately explains the tool's output and purpose. Lacks an output schema but describes return fields.

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 each parameter already described. The description does not add new semantic information beyond the schema's property descriptions.

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

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

Clearly states the verb 'list/paginate' and resource 'Disney character database' with explicit return fields (id, name, image URL, total count, total page count). Could improve by differentiating from the sibling 'search_characters'.

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?

Mentions 'useful for browsing the full catalog' but provides no when-not-to-use or explicit alternative. The sibling 'search_characters' exists but is not referenced.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds return field details and optional inactive parameter, reinforcing safe, 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?

Two concise sentences, front-loaded with purpose, no filler. Efficiently conveys everything needed.

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 lists return fields. Covers use context and parameter. Complete for a simple read-only tool.

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

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

Schema has 100% coverage for the single parameter. Description does not add extra meaning beyond the schema's own 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?

Clear verb 'List' and specific resource 'subscriptions'. Returns field names, distinguishing from siblings like subscribe/unsubscribe.

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

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

Explicitly states when to use: 'review what you're monitoring before adding more or to find an id to cancel.' 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?

The description discloses key behavioral traits beyond the annotations: rate limiting (5 per identifier per day), non-quota usage, the claim_token return mechanism, and the team's daily review process. These are not visible in the schema or annotations, so the description fills the gap thoroughly.

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?

Although the description is long, every sentence provides valuable information: purpose, scope boundary, claim_token flow, rate limits, and cost. It's front-loaded with the primary purpose and then layers details logically. No fluff or repetitive content.

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 and several parameters, the description supplies necessary context: when to use, what to include, how to track a submission, and constraints. It also explains the team's responsiveness, helping the agent set expectations. The description is sufficiently complete for correct invocation and follow-up.

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 useful semantics: it explains the claim_token parameter's dual purpose (filing vs. reading), and advises on message content ('don't paste the end-user's prompt'). This extra context elevates the parameter understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates specific use cases (bug, feature/data_gap, praise) and distinguishes itself from sibling tools by being the sole feedback channel for Pipeworx 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 when-to-use guidance with examples, and importantly provides a clear exclusion: tools from other MCP servers should be reported elsewhere. It also explains the claim_token workflow, effectively telling the agent how and when to use the tool for follow-up.

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 valuable context: data source (CF analytics-engine), no PII, caching behavior (5min-1h), and non-deterministic nature (self-aggregating signal). This goes beyond annotations without contradiction.

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

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

The description is well-structured: starts with purpose, then use cases, then implementation details. At 80 words, it is efficient and every sentence adds value. Could be slightly more concise but remains effective.

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

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

Given a single optional parameter and no output schema, the description covers purpose, usage context, behavior, and parameter semantics adequately. It vaguely mentions output fields (top tools, packs, volume) but lacks structure details. Still relatively complete for a simple tool.

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

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

With 100% schema coverage, baseline is 3. The description adds reasoning for parameter choices: 'Shorter windows surface what's hot right now; longer windows show steady-state demand', providing semantic guidance beyond the enum values.

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 returns 'top tools, top packs, and total call volume' from Pipeworx trending data, using specific verbs and resource identification. It distinguishes itself from siblings like 'discover_tools' by focusing on recent trends rather than general discovery.

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 lists three use cases (discovering hot data sources, confirming canonical tools, checking alignment) and implies read-only usage. However, it does not mention alternatives or when not to use among the 40+ sibling tools, which would improve guidance.

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

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

Annotations already declare readOnly=true, openWorld=true, idempotent=true, destructive=false. The description adds substantial behavioral context: partition_check logic, semantic anchor for cross-event, partition filter, and fill check details. It explains how results are computed and when signals are actionable, going beyond the annotation safety profile.

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 (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) and uses bold for key terms. Although lengthy, every sentence adds essential information for agent understanding. It is appropriately detailed 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?

Despite the absence of an output schema, the description thoroughly explains the response format: opportunities[] with fields, partition_check object, and fill_check fields. It covers edge cases (placeholder slugs, low similarity) and provides actionable guidance. The description is complete for an arbitrage detection tool.

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

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

Schema coverage is 100%, and the description adds significant meaning: it explains the difference between event and topic modes, how to format event slugs, and what each mode checks (date-axis ordering, partition sum, etc.). It also describes the response structure for each mode.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes: trending scan (no args), single-event (event slug), and cross-event (topic). This differentiates it from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

The description explicitly specifies when to use each parameter: no args for trending scan, event for a specific market, topic for cross-event scanning. It provides examples (slugs, seed questions) and warns about conditions where the trade should not be executed (realizable_edge_pp ≤ 0). It also mentions polymarket_fill_risk for custom sizing.

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

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

The description goes well beyond annotations (readOnlyHint, idempotentHint) by disclosing caching behavior (1h KV level), edge calculation details (FRED log-returns, GDELT, Kelly caps), slippage assumptions, and diagnostic output so agents understand behavior. 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 excessively long (over 400 words), burying important usage guidance in dense technical details about model families and response segments. It could be streamlined into a clear opening sentence followed by bulleted key points, but the front-loaded purpose is good.

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), the description provides thorough coverage: explains the three response segments, tradeable-edge knobs, diagnostics for empty results, and caching policy. This compensates fully for the missing 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?

All 9 parameters have schema descriptions (100% coverage), and the description adds further context, such as explaining slippage_pp with Polymarket fee data and min_partition_leg_kelly's interaction with partition arbs. This adds value beyond the schema, though some parameter descriptions in the schema are already quite clear.

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 scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, explicitly naming the use case 'what should I bet on today'. It distinguishes from siblings like polymarket_arbitrage by detailing its unique model families and segments.

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 mentions 'Built for what should I bet on today' implying when to use, and describes knobs for filtering (e.g., min_liquidity, max_spread_pp) that guide usage. However, it does not explicitly compare with sibling tools like polymarket_edge_tracker or polymarket_fill_risk, but the detailed segment explanation provides implicit differentiation.

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

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

Annotations already convey safety (readOnly, idempotent, etc.). The description adds significant behavioral detail: it uses snapshots, computes decay from daily closes (not intraday), explains response structure (tracked, expired, snapshot_dates), and notes that decay is based on |edge_pp_net| signed by trade direction. No contradictions with annotations.

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

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

The description is well-structured: starts with purpose, then args, then response format, finally limitations. It is informative but slightly verbose; could be trimmed slightly while retaining all needed context.

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

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

Given no output schema, the description explains the full response structure (tracked with trend/decay, expired with lifespan, snapshot_dates). It covers limitations (TTL, snapshotting start, intraday vs. daily closes). This provides complete context for an agent to understand what to expect.

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

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

Schema coverage is 100% with descriptions for both 'days' and 'window'. The description adds value by specifying defaults (14, '1wk'), max (30), and clarifying 'snapshot family' for window. This reinforces schema info and aids 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 provides 'edge persistence and decay telemetry' from daily snapshots, specifying the exact question it answers. It differentiates from sibling tools (e.g., polymarket_edges, polymarket_arbitrage) by focusing on historical persistence rather than current state or 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 gives clear usage context: it answers 'how long has this edge existed and is it shrinking?' and provides a concrete example contrasting a fresh vs. 3-week-old edge. It also notes limitations (60-day TTL, intraday not covered). However, it does not explicitly state when not to use this tool or recommend alternatives.

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

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

The description adds substantial behavioral context beyond annotations. It details what the tool does (walks ladder, returns fields like vwap_fill_price, slippage_pp, verdict) and warns about partial basket fills and forced directional risk. Annotations already indicate readOnlyHint=true, which aligns with description's 'check' nature.

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 headers for modes and front-loaded with the core function. However, it is somewhat verbose in places (e.g., lengthy explanation of basket fill risks). Still, every sentence adds value, earning a high score.

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

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

With no output schema, the description fully explains all return fields for both modes (top_of_book, vwap_fill_price, etc.). It also covers edge cases (thin legs, forced directional risk) and rationale. This is exceptionally complete for a complex dual-mode tool.

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

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

Schema coverage is 100%, but description adds significant meaning: explains mutual exclusivity of market/event, side defaults and auto-detection for baskets, and how size_usd is interpreted differently for single vs. basket modes (max spend vs. settlement notional). This goes well beyond the schema's basic descriptions.

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

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

The description clearly states the tool's purpose: it checks realizable vs. theoretical edge against live CLOB order-book depth. It explicitly distinguishes between single-market and basket modes, and differentiates itself from sibling tools like polymarket_arbitrage and polymarket_edges by specifying it is a pre-trade risk check.

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

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

The description provides explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why (partial fills convert arb to unhedged directional position), offering clear context and alternatives.

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

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

Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds significant behavioral context: explains output structure (leg-by-leg prices, matched spreads), safety fields (compatibility_warning, temporal_alignment, skipped counters), and conditions under which spreads are meaningless. No contradiction.

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

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

Well-structured with sections (TWO MODES, RESPONSE, SAFETY FIELDS) but somewhat verbose. Some redundancy (e.g., 'Real cross-venue spreads are rarer... pre-mapped ≠ tradeable' appears twice). Could be tightened without losing information.

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

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

Given complexity (multiple modes, safety fields, compatibility conditions) and no output schema, the description is exceptionally complete. Covers all output aspects, edge cases, and interpretations of safety fields.

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

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

Schema has 100% description coverage. Description adds meaning beyond schema: explains that topic is a pre-mapped macro list of 10 values, and explicit tickers override topic-mapped sides. Provides examples and interaction between parameters.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes two modes (topic shortcuts vs explicit tickers) and explains when spreads are meaningful. This differentiates it from sibling tools like polymarket_arbitrage.

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

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

Explicitly states when to use (comparing prices across venues) and when not to (when compatibility_warning fires due to non-equivalent bet shapes or no semantic relation). Warns that most pre-mapped topics return compatibility warnings, so pre-mapped ≠ tradeable.

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 behavioral context beyond annotations, such as scoping to an identifier and the relationship to remember/forget. 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 contributing distinct value: action, use cases, and scoping. It is front-loaded with the primary action and remains concise.

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

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

Given the tool's simplicity (1 optional parameter, no output schema), the description adequately covers retrieval, listing, scoping, and relationships to siblings. No gaps remain.

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

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

Schema coverage is 100% (key described as optional string). The description adds meaning by explaining the effect of omitting key (list all keys) and the purpose of the key ('Memory key to retrieve').

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

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

The description uses specific verbs ('retrieve', 'list') and clearly identifies the resource (values saved via remember). It distinguishes from sibling tools by naming 'remember' and 'forget' explicitly.

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 states when to use the tool ('look up context the agent stored earlier') and implies when not to use it ('without re-deriving it from scratch'). It also mentions scoping and pairing with remember/forget, providing clear context.

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

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

The description contradicts annotations: it states mark_read:true flags events read (a write operation), while annotations declare readOnlyHint=true (implying no state changes). This contradiction undermines trust in the tool's 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 brief yet comprehensive, front-loaded with the primary action. Each sentence adds value—covering parameters, alternative access, and polling advice—without redundancy.

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

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

Despite lacking an output schema, the description fully outlines return fields (source, citation_uri, payload), all parameter behaviors, and usage context (e.g., polling, alternative feed). It is self-sufficient for understanding 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 coverage is 100%, and the description adds rich semantics: it explains filter examples (e.g., 'sec_8k'), mark_read semantics, default limit (50), and since meaning, going well beyond the schema's raw 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 'Pull fired events from your subscription feed' with a specific verb and resource. It details what each returned event carries (source, citation_uri, raw payload), differentiating it from sibling tools like subscribe or 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?

The description advises filtering by type and since, explains polling suitability, and notes an alternative API endpoint. It lacks explicit exclusion of sibling tools but provides sufficient context for when 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 already declare readOnlyHint and idempotentHint, so safety is clear. The description adds valuable behavioral context: parallel fan-out to multiple sources, fallback logic (GDELT→GNews), and soft-fail for USPTO due to API sunset. 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 detailed and somewhat long, but every sentence adds necessary information (usage examples, source details, parameter guidance, sibling differentiation). It is well-structured and front-loaded with purpose, making it effective despite its length.

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

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

With no output schema, the description adequately describes return format (structured changes grouped by source, counts, citation URIs). It covers edge cases like PatentsView sunset and fallback logic. However, it could explicitly list the sources more compactly.

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 significant meaning beyond field names: explains that 'since' accepts ISO dates or relative shorthand with examples, recommends typical values, clarifies 'value' can be ticker or CIK, and confirms 'type' is only 'company'.

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

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

The description clearly states the tool provides a change feed for a company, listing specific query examples and contrasting with the sibling tool entity_profile. It identifies distinct data sources and the parallel call 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 explicitly advises when to use this tool ('what's new with X') and when to use the alternative entity_profile (static profile). It also provides examples of valid queries and guidance on the 'since' parameter (e.g., 'Use "30d" or "1m" for typical monitoring').

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 important behavioral details beyond annotations: scoping by identifier, persistence duration (permanent for authenticated, 24h for anonymous), and non-destructive nature (overwriting key-value pairs). No contradictions with idempotentHint=true.

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

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

Four sentences with front-loaded purpose, then usage, behavior, and tool pairing. No redundant phrases, 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?

Complete for a simple key-value store: explains when to use, what it does, behavioral nuances, pairing with siblings, and parameter usage. No output schema needed for such a tool; description covers return expectations implicitly.

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 concrete examples for keys (e.g., 'subject_property', 'target_ticker') and clarifies value accepts any text, which helps agents format inputs correctly.

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?

Clear verb 'save data' and specific resource 'key-value pair' with explicit use cases (resolved ticker, target address, user preference). Distinguishes from sibling tools recall and forget directly.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward... so you don't have to look it up again.' Also mentions pairing with recall and forget, and provides persistence context for authenticated vs anonymous users.

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

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail: supported entity types, exact return fields per type, upstream data sources (SEC EDGAR, RxNorm), citation URIs, and the fact that each call cascades through several lookup endpoints. This far exceeds what annotations already provide and contains no contradiction.

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

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

The description is dense but well-structured: it front-loads natural-language triggers, states the core use case in one sentence, and then organizes supported types with their specific inputs and outputs. There is no fluff or repetition; every sentence contributes useful information.

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

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

Despite having no output schema, the description fully covers the tool's input forms, output fields, data sources, citation behavior, and use case. It even explains that the tool replaces multiple manual lookups, giving the agent all context needed to invoke it correctly.

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

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

The schema descriptions cover both parameters 100%, so the baseline is 3. The description adds meaningful extra context, including auto-disambiguation, accepted input formats (ticker, CIK, name; brand vs generic), and the relationship between input value and returned identifiers, which enriches parameter 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 opens with concrete user-phrase examples and clearly states the tool resolves natural-language names to canonical/official identifiers. It distinguishes between company and drug entity types and names specific output fields, making the purpose unambiguous and differentiated from sibling tools like entity_profile.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID' and provides natural-language trigger examples, giving clear when-to-use context. It does not mention when not to use it or name alternative tools, so it falls just short of full 5.

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

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

The description adds behavioral context beyond annotations: it describes the internal workflow (probes each entity with ai_visibility_check, ranks by score), the output fields (score, confidence, signal density), and special handling (first entity as subject). This supplements the readOnly/ idempotent hints 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 two sentences plus a short quote, front-loaded with the main action. Every sentence adds value without repetition or filler.

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

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

Given 4 parameters, no output schema, but rich annotations, the description covers the tool's purpose, workflow, parameter nuances, and expected output. It lacks details on error handling or rate limits, but for a read-only idempotent tool, this is acceptable.

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 already has 100% description coverage. The description adds extra meaning: it clarifies entities array must be 2-8, first is subject, rest are competitors; explains 'models' defaults and API key requirement; and provides context on the 'context' parameter usage. This exceeds what the schema alone provides.

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

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

The description clearly states the verb+resource: 'Compare AI visibility across multiple entities side-by-side.' It distinguishes from sibling tool ai_visibility_check by explicitly mentioning multi-entity comparison and ranking, and provides a concrete use case quote.

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 a clear use case ('competitive AI-marketing audits') and implies the tool is for comparing multiple entities. It mentions that each entity is probed with ai_visibility_check, hinting that single-entity checks should use that tool directly. However, it lacks explicit when-not-to-use guidance or direct comparisons to siblings like compare_entities.

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

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

Description adds valuable behavioral details beyond annotations: fans out to external services, partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed will list failures. Annotations already indicate readOnlyHint, idempotentHint, etc., and description does not contradict.

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 fairly long but dense with useful information. Well-structured: starts with summary, then usage, then returned fields, then ecosystem constraint, then behavior notes. Almost every sentence adds value; only minor redundancy ('NPM ecosystem only in v1' could be merged with later note).

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 complexity of tool (two services, multiple data points, partial failures, timeouts) and absence of output schema, description fully covers what an agent needs: return structure, failure modes, timeouts, and constraints. No gaps identified.

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

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

Schema coverage is 100% (both parameters described in schema). Description adds minimal extra: mentions scoped packages are accepted and default version behavior, but these are already implied by 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 composite check for adding npm package, combining deps.dev and bundlephobia data. Specifies exact questions it answers ('is X safe/popular/small') and lists returned fields. Distinguishes from sibling tools by its specific niche.

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

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

Explicit usage guidance: 'Use whenever an agent asks...' and states it's only for NPM ecosystem in v1, with alternatives for other ecosystems mentioned. Provides concrete examples and constraints.

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 readOnly, openWorld, idempotent, nondestructive. Description adds that the tool returns appearances and image URL, and that matching is 'exact-ish', which clarifies behavior beyond annotations.

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

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

Two concise sentences front-loaded with purpose, examples, and return spec. 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?

Despite no output schema, the description adequately explains return fields (appearances, image URL) and matching behavior. However, it does not reference sibling tools or describe ordering/pagination, leaving minor 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 covers both parameters (name, limit) with descriptions. The description adds 'exact-ish' matching qualifier for name, and examples demonstrate usage, adding value beyond schema.

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

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

Description clearly states the tool searches the Disney character database by name, with examples and brief return spec. It distinguishes from exact match tools (e.g., get_character) by noting 'exact-ish' matching, but does not explicitly contrast with list_characters.

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 implicitly says to use this tool for name-based search and gives examples, but does not provide explicit when-to-use vs. siblings (get_character, list_characters) or conditions to avoid.

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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant behavioral details: BGE-base-en embeddings, cosine similarity over 500-char windows, 200K char limit with truncation flag, and character offsets for verification. 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?

Approximately 5 sentences, front-loaded with the core purpose, then usage, then technical details. Every sentence adds value with no redundancy or filler.

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

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

All aspects are covered: input (text, query, limit), output (passages, offsets, scores), constraints (200K chars, max 20), mechanics (BGE, cosine, windows), and integration pattern (pairing with ask_pipeworx_grounded). 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%, baseline 3. The description adds value with examples for 'text' (e.g., SEC 10-K body) and 'query' (e.g., 'supply-chain risk'), and clarifies output behavior (passages with offsets and scores). However, it does not add new parameter semantics beyond what the schema provides.

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

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

The description clearly states the tool performs 'Semantic search INSIDE a fetched record', specifying the verb (search), resource (a fetched record/text), and scope. It distinguishes from siblings like 'ask_pipeworx_grounded' by mentioning pairing and from general search tools by emphasizing it works on already-fetched text.

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

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

Explicit when-to-use guidance: 'Use when the record is too big to cram into the prompt — search_within saves context...' It also mentions pairing with ask_pipeworx_grounded and provides examples of queries. No explicit 'when not', but the context is clear.

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

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

Discloses OAuth requirement, persistent subscription nature, delivery constraints (e.g., phone verification, 10/day SMS cap, webhook auto-disable). Adds context beyond annotations (idempotentHint=true but description implies new ID per call – not a contradiction worth flagging).

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 long but well-structured with clear categorization of types and delivery. Every sentence adds value; could be slightly more streamlined but is still 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?

Covers prerequisites, supported types, delivery options, return value ('Returns the new subscription id'), and constraints. No output schema, but description compensates fully.

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 description adds extensive examples and constraints for each type and delivery channel (e.g., exact item codes for sec_8k, webhook HMAC signing). This significantly enriches 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 creates a subscription to a live-data event stream and returns the subscription ID. It distinguishes from sibling tools like 'unsubscribe' and 'list_subscriptions' by explaining the creation nature.

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 requirement for Pipeworx OAuth account and explains anonymous/BYO limitations. Provides detailed examples for each subscription type and delivery channel, guiding when to use each variant.

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 fully cover safety (readOnly, idempotent, non-destructive). The description adds behavioral context about the return format—category-bucketed example questions with exact tool and argument shapes—and that it draws from a live catalog. No contradiction with annotations.

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

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

The description is relatively long but well-structured: it starts with user-facing questions, then states purpose, then details return content, categories, and usage. It is front-loaded with key information, though some redundancy exists (e.g., listing categories twice).

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

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

The description fully explains the tool's purpose, return value (example questions with tool shapes), optional parameter usage, and when to call it (first step). Despite no output schema, the description adequately describes the return content. No gaps remain.

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

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

Schema coverage is 100% (one optional param 'topic'). The description adds value beyond the schema by listing example topics ('finance', 'pharma', etc.) and explaining to omit for a cross-category spread, clarifying usage beyond the basic definition.

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's an onboarding entry point that returns category-bucketed example questions with tool shapes. It uses specific verbs ('Returns', 'Call') and explicitly distinguishes itself as the first tool to use when unfamiliar with Pipeworx, differentiating it from siblings like ask_pipeworx and discover_tools.

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

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

The description provides clear context for when to use the tool: 'FIRST when you do not yet know what Pipeworx can do for you' and 'to learn how to call the meta-tools'. It implies alternatives by mentioning other tools, but does not explicitly state when not to use it or contrast with all 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 indicate mutation (readOnlyHint false) but description adds that it deactivates rather than deletes and that historical events stay available. This provides valuable behavioral context beyond annotations.

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

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

The description is two sentences, with the purpose in the first sentence and constraints/side effects in the second. No redundant information.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, ownership, and side effects completely.

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

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

Schema has 100% coverage for the single parameter, so description adds little extra beyond restating the parameter's purpose. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'cancel' and the resource 'subscription'. It distinguishes the tool from siblings like 'subscribe' and 'list_subscriptions' by explicitly being the cancellation action.

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 states ownership enforcement ('you can only cancel your own subscriptions'), providing clear context for when to use. It does not explicitly exclude alternatives but adequately guides 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 indicate read-only, open-world, idempotent, non-destructive behavior. The description adds behavioral details: uses structured SEC pipeline for financial claims, grounded pipeline for others, returns verdict with evidence and reasoning, and replaces multiple sequential calls. 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 dense paragraph that packs a lot of information without verbosity. It includes examples, processing details, and return structure. No unnecessary sentences.

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

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

Given two parameters and no output schema, the description adequately explains return values (verdict, actual value, reasoning). It covers the main use cases and pipeline. Missing details like error handling or edge cases, but acceptable for this complexity level.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context for tolerance_pct (default implied by wording, override for hallucination detection) but does not significantly expand beyond the schema 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 explicitly states it is for natural-language claim verification against authoritative sources, provides example queries like 'Is it true that…' and 'fact check', and distinguishes between financial claims (via SEC EDGAR) and other claims (grounded pipeline). It clearly differentiates from sibling tools like ask_pipeworx_grounded by focusing on verification with a verdict.

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

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

The description says 'Use whenever the agent needs to check whether something a user said is factually correct,' which is clear. It also details two processing paths for financial vs. other claims. While it doesn't explicitly list when not to use, the context is sufficient for an agent to decide.

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