Mime

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds that it probes LLMs, defaults to Workers AI Llama-3.3-70b, and requires BYO key for Anthropic. It notes that users pay Anthropic directly for those calls, which is beyond what annotations provide.

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

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

The description is a concise paragraph with two main sentences and a bullet-like list of return fields. Every sentence adds value: purpose, default model, API key usage, return format, and use cases. No fluff.

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

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

Given no output schema, the description adequately summarizes the return structure (score, confidence, signals, raw_response, combined view). It covers all parameters and use cases. A slight gap is lacking an example response, but overall it is sufficiently complete.

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

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

Schema covers 4 parameters with 100% coverage. The description adds semantic value: explains the default model, how models parameter works, that _apiKey is passed through to Anthropic, and that context disambiguates. This goes beyond the schema's bare 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 probes LLMs for entity visibility and scores it (0-100) per model. It specifies the verb 'probe' and resource 'LLMs', and distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on visibility scoring for any business/brand/product/topic.

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

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

The description includes explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It guides when to use the API key, but does not state exclusions or alternatives. However, the context is clear enough for an agent to decide when to invoke 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 cover the safe, read-only, idempotent, open-world nature of the tool. The description adds meaningful behavioral context beyond that: it routes to the right sub-tool, fills arguments automatically, returns structured answers, and emits stable pipeworx:// citation URIs. No contradiction with annotations; only minor operational details like rate limits or latency are absent.

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

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

The description is long but front-loaded with 'PREFER OVER WEB SEARCH' and organized into scope, examples, and alternatives. The example list is slightly longer than strictly necessary, but every section earns its place by supporting selection and invocation. It is structured well enough that an agent can quickly extract the core directive.

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

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

There is no output schema, so the description's statement that it 'returns the structured answer with stable pipeworx:// citation URIs' is important and sufficient. It covers what the tool does, when to prefer it, how to phrase inputs, and which sibling to choose for stricter grounding or broader research. Given the annotations cover side effects, nothing critical is missing for correct 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?

The input schema has 100% coverage: all six parameters are fully documented, with five explicitly listed as aliases for 'question'. The description adds example questions and trigger phrases but no new parameter-level semantics. Since the schema already does the heavy lifting, 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?

States a clear verb+resource: it routes a natural-language question to one of 5,798 tools across 1,517 verified sources and returns a structured answer with citation URIs. The long category list (SEC, FDA, FRED/BLS, USPTO, etc.) makes the resource scope concrete, and the explicit 'PREFER OVER WEB SEARCH' positioning distinguishes it from generic search and from siblings like ask_pipeworx_grounded and deep_research.

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...', trigger phrases like 'what is', 'look up', 'get the latest', and concrete example questions. It also names alternatives: ask_pipeworx_grounded for absolutely verified grounded citations, and deep_research for broad multi-part questions. This gives both positive selection criteria and clear exclusion conditions.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds meaningful context beyond those: candidate routing improvements, the current no-candidate state with a retirement date, identical response shape, and a clear statement that this is a full working router rather than a fallback wrapper. This does not contradict any annotation.

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 reasonably compact and well-structured: definition first, current status second, usage guidance last. The final 'Falls back to nothing' sentence is slightly cryptic, but it is immediately clarified by the next clause, and there is no filler.

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

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

For a read-only, idempotent router with a fully documented schema, the description covers purpose, current experimental state, relationship to the stable sibling, and return shape via 'same response shape.' It does not explain the routing mechanism in depth, but an agent has enough information to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description only says 'same arguments' and adds no parameter-level detail, but the schema itself already documents all six parameters and their aliases clearly.

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

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

The description names a specific resource ('beta version of ask_pipeworx') and states its function as a universal router with the same 5,798 tools, arguments, and response shape. It clearly differentiates the tool from the stable sibling by the candidate-routing experiment, so an agent can understand exactly what this tool is for.

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

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

The description gives an explicit use condition: 'Use it exactly like ask_pipeworx when you want the newest routing,' and explains that results are compared against the stable router. It does not explicitly say 'use ask_pipeworx when you need stability,' but the beta and experimental framing strongly implies the alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint:false. The description adds substantial behavior beyond those: it extracts answers ONLY from tool results, returns a structured refusal object with specific refusal_reason values, and discloses that it costs an extra LLM call. It also reveals that routing is identical to ask_pipeworx, which is important operational context.

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

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

The description is long but information-dense, and every clause earns its place: mode, routing scope, extraction constraint, return contract, refusal reasons, use cases, and cost tradeoff. It front-loads the core purpose and then supplies operational guidance. There is no filler or repetition.

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 supplies the full return contract on success and failure, including refusal_reason variants. It also covers routing behavior, evidence format, and when to prefer the cheaper sibling. For a tool with this complexity, the description gives an agent everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, and the schema already documents the single question parameter plus five aliases. The description mentions that the tool "fills arguments" but does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate since the schema fully covers 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 defines a specific, distinct mode: a hallucination-resistant grounded answer mode for high-stakes reads. It names the resource (Pipeworx routing over 5,798 tools/1517 sources), describes the extraction behavior, and clearly contrasts with ask_pipeworx by emphasizing evidence-based answers and refusals. This makes it immediately distinguishable from sibling tools.

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

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

It explicitly states when to use the tool: "Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts," with concrete examples like financial verdicts and legal claims. It also tells the agent when not to use it: "prefer ask_pipeworx for casual lookups," and explains the cost tradeoff of one extra LLM call. This is exemplary usage 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds extensive behavioral details: market resolution/classification, fan-out logic, response shapes, resolver contract (confidence levels, alternatives), parent event extractor, news fallback handling, safety for low-confidence matches, closed markets, wide spreads, and resolution-rule risk. No contradiction with annotations.

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

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

The description is comprehensive but quite lengthy, with multiple paragraphs covering many specifics. While well-structured with sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.), it could be more concise without losing essential information. Some details (e.g., specific fan-out examples) are helpful but add to verbosity.

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

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

Given no output schema, the description thoroughly explains return shapes: analysis, evidence, market fields, resolver confidence, parent event, news fields, and safety mechanisms. It covers all relevant aspects an agent needs to understand and use the tool effectively, including edge cases (closed markets, wide spreads, resolution risks).

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 all three parameters. The description adds value beyond the schema: explaining that 'market' can be a slug, URL, or question text; detailing 'depth' enum values ('quick' vs 'thorough'); and clarifying when to set 'include_raw' to true. This enhances usability.

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 ('Research') and resource ('Polymarket bet'), detailing the process of pulling Pipeworx data, classification, fan-out, and returning an evidence packet with comparison. It distinguishes itself from sibling tools like polymarket_arbitrage or polymarket_edges by its comprehensive research scope.

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

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

Explicit usage contexts are provided: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' The description also gives examples of when to use different parameters (e.g., include_raw). It does not explicitly state when not to use the tool, but the context is clear enough.

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

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

Rich description beyond annotations: explains data sources for each type, handling of off-calendar fiscal years, sorting behavior, and citation URIs. No contradiction with annotations (readOnlyHint=true consistent with 'pulls' data).

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

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

Front-loaded with key trigger phrases and purpose, every part adds value. Slightly verbose but still efficient for the complexity covered.

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 purpose, when to use, data sources per type, sorting behavior, and output format (paired data + citations). No output schema required explanation. Complete for a comparative analysis 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?

Adds significant meaning beyond schema: details what each enum value does, gives concrete examples for 'values' (tickers/CIKs for company, names for drug), and explains sorting prioritization.

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?

Begins with natural language triggers like 'Compare X and Y', clearly stating it performs side-by-side comparison of 2-5 companies or drugs in one parallel call. Distinguishes from sequential single-pack lookups.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups', giving clear when-to-use advice. Implicitly suggests alternative is multiple entity_profile calls. Lacks explicit 'do not use if' conditions but context is sufficient.

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

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

The description goes far beyond the readOnly/openWorld/idempotent annotations. It discloses failure behavior ('explicit gaps[]', 'never invented'), depth-specific extra hops, contradiction scanning, citation fetchability, semantic excerpting of large records, and expected latency. No contradiction with the annotations exists.

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

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

The description is long but information-dense, with the most critical gating information (account requirement) front-loaded. Some phrasing is run-on and repetitive ('one call' appears multiple times), but nearly every sentence contributes a distinct behavior, constraint, or routing rule. It earns its length for a tool with this 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?

For a complex research tool with no output schema, the description fully covers return values (findings packet, verbatim evidence, confidence, source, fetched_at, citation), auth requirements, depth modes, expected timing, failure handling, and when to use alternatives. Nothing an agent needs to decide or invoke correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra parameter context: depth:'thorough' requires a paid plan, quick=3 facets, standard=3 with gap-recovery and contradictions, thorough=6 with iterative lead-chasing. This goes beyond the schema's enum descriptions, justifying a 4.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources' in 'ONE call.' It clearly distinguishes itself from open-web search and names the sibling it is not ('For a single lookup use ask_pipeworx instead'). This gives an agent a precise, differentiated 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?

Usage guidance is explicit: 'If you are not signed in, use ask_pipeworx instead' and 'For a single lookup use ask_pipeworx instead.' It also gives concrete examples of when deep_research is best ('broad/multi-part questions over structured data'). No ambiguity about when to choose this tool versus an alternative remains.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' This provides actionable behavior details beyond annotations.

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

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

The description is a single paragraph of 5 sentences, each adding value: purpose, domain examples, output format, usage guidance. No redundant information. It is front-loaded with the core verb and resource.

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 adequately covers what the tool does, when to use it, and what it returns. No output schema exists, but the textual description of the output is sufficient. The limit parameter's default (20) and max (50) are in the schema, not description, but that is acceptable. Overall, it is complete for a discovery tool with strong 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 6 parameters, all documented. The description adds example queries like 'look up FDA drug approvals' and 'analyze housing market trends', which help the agent form correct inputs. However, the description does not add significant new details beyond the schema, so a baseline of 3 is adjusted upward to 4 for the helpful examples.

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

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

The description starts with 'Find tools by describing the data or task', clearly stating the verb (discover) and resource (tools). It lists specific domains (SEC filings, FDA drugs, etc.) and explains the output (tool names, descriptions, schemas). This clearly distinguishes it from siblings like 'search_within' which operate on already known 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 explicitly states 'Use when you need to browse, search, look up, or discover what tools exist' and advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use and when-not-to-use guidance, though no explicit alternative tools are named.

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

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

Even though annotations already declare readOnlyHint/openWorldHint/idempotentHint, the description adds substantial behavioral context: it fans out across SEC EDGAR, XBRL, USPTO, USAspending, FDA Purple Book, DOL LCA, GDELT/GNews, and GLEIF; explains soft-fail behavior for patents; clarifies that an empty fda_products section is expected; and defines sources_used/sources_failed semantics as real no-data signals rather than bugs.

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

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

The description is long but dense and front-loaded with purpose and usage before enumerating sources and return fields. Every sentence adds operational detail, though the seven opening example phrasings and the explicit restatement of type interchangeability are slightly redundant with the schema.

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 carefully enumerates the returned sections (cik, company_name, recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), explains URI formats, describes edge cases (private companies, patent API sunset, empty FDA products), and tells the agent how to interpret sources_used/sources_failed. An agent has enough information to call and interpret the tool correctly.

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

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

With 100% schema coverage the baseline is 3, but the description goes beyond the schema by explaining that 'type' accepts company/ticker interchangeably, that 'value' may be a ticker, zero-padded CIK, or company name, and that names resolve via SEC EDGAR with a resolved:false + notes result for private companies. Some of this is restated in the schema, but the edge-case detail materially improves parameter understanding.

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

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

The description opens with concrete user phrasings and immediately states the tool provides a 'full cross-source profile of a US public company in ONE parallel call.' It specifies the action (profile), the resource (US public company), and distinguishes itself from 'chaining single-pack SEC/XBRL/news lookups,' making it easy for an agent to identify when this tool applies.

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

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

It gives explicit context for use: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and lists the accepted input forms. It does not explicitly state when not to use it or name alternatives such as compare_entities or resolve_entity, so it falls just short of fully exhaustive routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so tool is safe. Description adds 'Keyless, offline', which gives additional transparency about no dependencies and network usage, exceeding what annotations provide.

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

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

Single sentence that starts with the action verb and includes a clear example and key attributes (keyless, offline). No superfluous words; every part earns its place.

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

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

For a simple offline lookup with one parameter, the description is sufficient. It covers purpose, example, and unique traits. It could optionally note that the result is a list or mention case sensitivity, but these are minor additions. Given no output schema, the example partially compensates.

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

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

Input schema has 100% coverage (one param 'mime' described). Description adds value by showing an example with multiple extensions returned ('jpg','jpeg'), clarifying that the output is a list and that one MIME type can map to several extensions.

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

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

Description clearly states the action: 'Get the file extension(s) for a MIME type' with a concrete example ('image/jpeg' -> ['jpg','jpeg']). It distinguishes from sibling tool 'lookup_mime' (reverse direction), making purpose unambiguous.

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

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

Description implies when to use: when you need extensions from a MIME type, especially offline (no network) and without keys. However, it does not explicitly state when not to use or mention alternatives like 'lookup_mime', but the contrast is clear from the example and sibling 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?

Description aligns with annotations (destructiveHint=true, readOnlyHint=false). No additional behavioral context beyond what annotations provide, but no contradiction.

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

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

Two sentences: first delivers core purpose, second adds usage guidance. No unnecessary words, front-loaded.

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

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

Tool is simple (1 param, no output schema) and annotations are present. Description is sufficient for correct invocation.

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

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

Schema coverage is 100% and description for parameter 'key' is basic. Description does not add extra meaning beyond the schema's 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 'Delete a previously stored memory by key', which is a specific verb+resource. It distinguishes from siblings 'remember' and 'recall' by focusing on deletion.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also mentions pairing with related 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 indicate readOnly, idempotent, non-destructive behavior. The description adds value by explaining the extraction process (fetches page, extracts title/description/links) and output format (single text blob for site-root/llms.txt). No contradiction.

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

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

Two sentences with effective colon list, front-loaded verb+resource, every sentence adds unique value with no redundancy.

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

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

For a simple 2-parameter tool with full schema coverage and rich annotations, the description fully covers purpose, process, output, and use cases.

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

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

Input schema covers 100% of parameters with descriptions. The tool description rephrases 'max_links' default but adds no additional semantic detail beyond the schema, so baseline 3 applies.

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

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

The description clearly states the verb 'generate' and resource 'llms.txt file for any URL', and distinguishes it from sibling tools by specifying it produces a standard markdown format for AI crawlers.

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

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

The description lists three explicit use cases (client's site, own project, competitor audit) but does not provide exclusions or alternatives, leaving some ambiguity about 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, idempotentHint, destructiveHint. Description adds only 'active subscriptions' behavior, which is consistent but not additional beyond annotations.

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

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

Two sentences with no wasted words; first sentence front-loads purpose and return fields, second provides usage guidance.

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 single optional parameter, no output schema, and comprehensive annotations, the description is complete enough for an AI agent to use the tool effectively.

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

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

Schema covers 100% of parameters with description for include_inactive. Description does not add extra semantic 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?

Description clearly states 'List the caller's active subscriptions' with specific verb and resource, lists return fields, and distinguishes 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?

Provides explicit use case: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Does not explicitly state when not to use, but context is clear given sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc., covering behavioral safety. The description adds value by noting 'Keyless, offline' and providing an output example. It does not mention error handling for invalid inputs, but overall transparency is good.

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

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

The description is extremely concise: one sentence with an example and a short note 'Keyless, offline.' No wasted words; every part earns its place.

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

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

Given no output schema, the description provides an output example ('image/png'), which is sufficient. Annotations cover safety, and the parameter is fully documented. The tool is simple and the description is complete 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 description coverage is 100%, with the parameter 'file' well-described. The description adds context by showing the output format and confirming offline operation, which goes beyond the schema. The baseline of 3 is exceeded because of added value.

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

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

The description clearly states the tool's purpose: to get the MIME type for a filename or extension, with a concrete example. It uses a specific verb (get) and resource (MIME type), and the purpose is distinct from all sibling tools, which are unrelated.

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 'Keyless, offline' which gives context on when to use (no API key needed, offline), but it does not provide explicit guidance on when not to use or mention alternatives. Given the tool's simplicity, the implied usage is clear, but lacking explicit when-not-to-use prevents a higher score.

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 are all false, providing no safety signals, so the description carries the full burden. It discloses key behaviors: rate limiting ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), the claim_token flow ('Filing without an account returns a claim_token; pass it back later...'), and that 'The team reads digests daily and signal directly affects roadmap.' No contradictions with annotations.

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

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

The description is long but every sentence earns its place—nothing is wasted. It front-loads the main purpose and then logically covers usage, scope, claim_token flow, rate limits, and cost. Slightly verbose but highly informative; a 4 for structure without being overly terse.

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 and complex behavior (nested context object, optional claim_token), the description is remarkably complete. It explains the return flow (claim_token for anonymous filing), the scope constraint, the daily digest and roadmap impact, and the exact parameter combinations. There are no significant gaps in understanding how to use 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%, so the baseline is 3. The description adds meaning beyond the schema by explaining the claim_token usage in detail ('Read the reply to a report you filed earlier: pass the pwfb_… token that filing returned, with no other arguments') and clarifies the type categories (bug, feature, data_gap, praise) in context. It reinforces but doesn't dramatically expand on the schema, hence a 4.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It specifies the resource (Pipeworx team), the action (send feedback), and differentiates from siblings by focusing exclusively on feedback for Pipeworx tools, not other MCP servers.

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

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

Explicit usage guidance is provided: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also clearly states when not to use it (feedback for non-Pipeworx MCP servers) and tells users to file with that server instead.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: self-aggregating from CF analytics-engine, no PII, caching policy (5min-1h). 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?

Three compact sentences with bullet points for use cases. Every sentence adds unique value with no redundancy.

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

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

Given a simple single-parameter tool with rich annotations, the description is complete: it explains what it returns, how it works, and important notes (no PII, caching). No output schema needed.

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

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

Schema coverage is 100% with a single enum parameter fully described. The description adds context on window semantics (short for hot, long for steady-state), enhancing the schema's meaning.

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

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

The description clearly states the tool returns what other AI agents are calling on Pipeworx, including top tools, packs, and call volume. It uses specific verbs (returns, discovering, confirming, seeing) and distinguishes from siblings by focusing on trending metrics.

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

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

Three explicit use cases are listed, providing clear context for when to use the tool. While it doesn't explicitly mention when not to use, the guidance is strong enough for agents to decide alignment.

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 read-only, idempotent, non-destructive. The description adds extensive behavioral details: semantic anchor (Jaccard threshold), partition filter, fill check with book depth, and response structure, far exceeding annotation scope.

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 verbose but well-structured: first sentence summarizes, then modes, then technical details. Every sentence adds value, though length could be trimmed for quicker parsing.

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

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

No output schema, but description fully documents response fields, includes fill check logic, and references related tool (polymarket_fill_risk). 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%, but description adds rich meaning with examples ('fed-decision-may-2026'), explains mode behavior, and outlines the scanning logic, significantly enhancing understanding beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, and distinguishes three modes (no args, event, topic) with specific behaviors, differentiating it from siblings like polymarket_edges.

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

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

Explicit guidance on when to use each parameter mode: 'Call with NO args for a trending_scan... pass event for... or topic for...' Includes examples and explains cross-event mode catches patterns single-event misses, providing clear context for selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds extensive behavioral context: caching at KV level, response structure with by_segment and diagnostics, fed signal reliability note, and filter logic. 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 lengthy but well-structured with clear sections and front-loaded purpose. Every sentence adds value, though it could be slightly more concise without losing detail.

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

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

Given the complexity (9 parameters, no output schema, many siblings), the description is highly complete: it explains response top-level fields, diagnostics, caching, and fed note. No output schema needed as description covers return value structure.

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

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

Schema coverage is 100% with parameter descriptions. The tool description adds extra context (e.g., slippage explanation, tradeable-edge filter purpose) beyond the schema, providing meaningful guidance even though baseline is met.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, with a specific verb+resource and differentiation from siblings like polymarket_arbitrage through mention of unique model families.

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

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

Provides clear context: 'Built for what should I bet on today' and includes when-not guidance via fed_candidates exclusion note and placeholder-slug filter. However, does not explicitly compare to alternative sibling tools for when to use them instead.

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 safe read-only behavior, and description adds substantial behavioral details: time-series, trend classification, decay computation, snapshot gaps, and limits (60-day TTL, daily closes). No contradictions.

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

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

Description is compact but information-dense. Front-loads the core purpose, then systematically covers arguments, response fields, and limits. 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?

No output schema exists, but the description fully defines the response structure (tracked, expired, snapshot_dates) with field explanations and limits. Complete for a tool of this complexity.

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

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

With 100% schema coverage, baseline is 3. The description adds significant meaning: explains days clamping (2-30), window family options, and the full response structure (tracked/expired/snapshot_dates) with field semantics, far exceeding the schema's minimal descriptions.

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

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

The description explicitly states the tool answers 'how long has this edge existed and is it shrinking?' with a specific verb-resource combination (edge persistence telemetry). It clearly distinguishes from sibling polymarket_edges, which likely returns current edges without historical context.

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

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

Provides context on when to use: to differentiate between fresh and old edges. Implies usage for assessing edge persistence but does not explicitly state when not to use 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 readOnlyHint, idempotentHint, and non-destructive, which the description aligns with. The description adds detailed behavioral context: walks the order book, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and explains basket mode risks (thin_legs, forced directional risk). 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 relatively long but dense with information. It is front-loaded with purpose and usage guidelines, followed by mode details. Each sentence adds unique value, though some repetition of field names could be trimmed. Overall, it appropriately balances detail and brevity.

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

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

Given the complexity (two modes, multiple return fields, edge cases like thin legs and directional risk), the description is remarkably complete. It lists return fields for both modes, explains default behaviors, and warns about partial fills. No output schema exists, but the description compensates well.

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 all parameters. The description adds valuable context beyond schema: explains mode selection (market vs event), default behaviors for side and size_usd, and business meaning of size_usd in basket mode (settlement notional). A minor gap: size_usd clamp range is in schema but not repeated in description.

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

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

The description clearly states it is a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It explicitly differentiates from sibling tools by advising use before polymarket_arbitrage or polymarket_edges trades, making purpose and differentiation evident.

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

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

The description provides 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 also explains why (theoretical overround not capturable, partial fills create directional risk), effectively guiding agent decision-making.

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 the readOnlyHint/idempotentHint annotations by disclosing that pairings are unverified keyword matches, that temporal_alignment null means unknown not aligned, that spreads are gross of Kalshi fees, and that certain legs are never paired. It also explains the meaning of each compatibility code and flag. This is exemplary behavioral disclosure for a no-output-schema tool.

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

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

The description is well-structured with capital-letter section labels and front-loaded purpose, but it is extremely long for a 3-parameter tool and repeats itself in places (e.g., compatibility codes are listed twice, flags appear in a list and again in top_spreads_pp). Each sentence carries information, but a tighter rewrite would improve scannability.

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

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

With no output schema to lean on, the description fully specifies the response shape: leg-by-leg prices, top_spreads_pp, compatibility fields, temporal_alignment, fees_note, skipped counters, and low_confidence_pairs. It even warns about interpretation pitfalls, making it complete for an agent to call correctly.

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

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

Schema coverage is 100%, and the description adds crucial semantics: it enumerates all 10 topic shortcuts verbatim, explains that kalshi_event_ticker and polymarket_event_slug override the topic-mapped side, and clarifies that both modes run the same matcher. This adds material meaning beyond the input schema.

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

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

The description opens with a specific verb and resource: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It clearly distinguishes itself from sibling tools by naming the two platforms and explaining the core output (spread in percentage points).

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 thoroughly explains when to use the tool: two modes (topic shortcuts vs. explicit ticker/slug) and specifies which parameters override which. It also warns that most pre-mapped topics return compatibility_warning today. However, it never explicitly contrasts this tool with closely related siblings like polymarket_arbitrage, so exclusions/alternatives are left implied rather than named.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds scoping (by identifier) and behavior when key is omitted (list all keys). 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?

Three well-structured sentences: purpose, use case, scoping/pairing. No wasted words. Front-loaded with the primary 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?

No output schema, and description does not explain the return format (e.g., type of value, structure for list). Otherwise covers usage, scoping, and relationships with siblings.

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

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

Schema coverage is 100%, and description explains the key parameter's role (retrieve specific key or omit to list all). This adds value beyond the schema's field description.

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

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

The description uses specific verbs ('retrieve', 'list') and resources ('value previously saved via remember', 'all saved keys'). It clearly distinguishes from siblings 'remember' and 'forget' by stating its complementary role.

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

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

Explicitly states when to use ('look up context the agent stored earlier') and implies when not to (save/delete via siblings). Also mentions scoping and pairing with remember/forget.

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, destructiveHint false. Description adds behavioral details: returns specific fields, mark_read side effect (flagging events read), and alternative REST access. 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?

Front-loaded with core purpose, then details fields, filtering, mark_read, and alternative access. Each sentence adds value; could trim the REST endpoint mention but not excessive.

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?

Adequate for a read-only feed tool with 5 optional params and no output schema. Describes return fields, polling suitability, and alternative access. Could mention pagination or behavior with no new alerts, but not critical.

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

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

Schema covers all 5 params with descriptions. Description enriches semantics: gives type example 'sec_8k', explains mark_read effect ('so next call only shows newer ones'), clarifies since as ISO timestamp. Adds 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 it pulls fired events from subscription feed, returns recent alerts with specific fields (source, citation_uri, raw payload). Distinguishes from sibling tools like list_subscriptions and subscribe by focusing on event data rather than subscription management.

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

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

Provides context on when to use (polls work fine) and mentions alternative access via REST endpoint. Lacks explicit comparison to sibling tools or conditions for not using, but gives clear filtering guidance (by type and since).

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?

Read-only, open-world, idempotent hints are already in annotations. Description adds details about multi-source fan-out, GDELT→GNews fallback, USPTO soft-fail, and response structure. 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?

Front-loaded with example queries and organized logically. While fairly dense, all sentences contribute useful information, but minor redundancy could be trimmed.

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

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

No output schema exists, but description completely explains return format (changes[] grouped by source, total_changes, pipeworx:// URIs). Covers edge cases like GDELT rate limiting, USPTO sunset, and relative date handling.

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 3. Description adds value by explaining relative shorthand formats (e.g., '7d', '30d', '3m', '1y'), default recommendation '30d', and acceptable values for 'value' (ticker or CIK).

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

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

The description clearly defines the tool as providing a change feed for a company covering SEC filings, news, and patents. It uses specific verbs and resources and explicitly distinguishes from the sibling tool '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?

Provides explicit query examples like 'what's new with X' and tells when to use 'entity_profile' instead. Also explains fallback behavior between GDELT and GNews.

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

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

Adds significant context beyond annotations: memory is scoped by identifier, authenticated users get persistent memory, anonymous sessions retain for 24 hours. No contradiction with annotations (idempotentHint=true, destructiveHint=false).

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

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

Three concise sentences front-loaded with purpose, then usage, then storage details. Every sentence adds essential information 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?

Complete for a simple tool: covers purpose, when to use, storage semantics, scoping, persistence/ttl, and mentions sibling tools. Output schema not needed.

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 adequate parameter descriptions. The description adds value by explaining key-value storage and providing examples (e.g., 'key: subject_property'), raising it above baseline of 3.

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

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

The description clearly states 'Save data the agent will need to reuse later' with specific verb and resource. It distinguishes from sibling tools 'recall' and 'forget' by explicitly mentioning them.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and provides concrete examples (resolved ticker, target address, user preference, research subject). Also contrasts with recall and forget.

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, and idempotent behavior, and the description adds substantial non-obvious context: cross-source identifier enrichment, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` output, `figi_candidates` disambiguation, and multi-endpoint internal cascading. No annotation contradiction exists.

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

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

The description is dense and somewhat long, but it is front-loaded with user-intent examples and the key instruction, then methodically covers supported types and edge cases. Almost every sentence adds value, though tighter editing could reduce redundancy in the company-type explanation.

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 two-parameter tool with no output schema, the description supplies sufficient behavioral detail, return-edge-case behavior, fallback semantics, and input validation guidance. An agent can both select and invoke the tool correctly without additional context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes far beyond the schema: it enumerates valid company inputs (ticker, CIK, ISIN, name), explains the value 'value' should contain, and provides a specific negative example warning against passing full noun phrases. This materially improves invocation correctness.

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 natural-language queries and a crisp statement: resolve a user-spoken NAME to canonical identifiers other tools require. It clearly distinguishes the tool from siblings like entity_profile or compare_entities by positioning it as the lookup step before other tools are invoked.

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,' giving strong selection guidance. It does not name alternatives or state when not to use it, but the supported types and input formats make the applicable context unmistakable.

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?

Describes output (ranked list with score, confidence, signal density) beyond annotations. No contradictions with annotations (readOnly, idempotent). Non-destructive nature implied by annotations and description.

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

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

Three sentences, front-loaded with purpose and behavior. No redundant information. 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?

Adequately describes high-level output despite no output schema. Covers return fields. Lacks details on score computation, but sufficient given complexity and 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%, baseline 3. Description adds value by explaining that first entry is 'subject' for narrative and that models can be omitted for default. This aids parameter understanding.

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

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

Description clearly states the tool compares AI visibility across multiple entities, ranks them, and identifies most/least recognized. It distinguishes from sibling 'ai_visibility_check' which checks a single entity.

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

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

Explicitly states use case: competitive AI-marketing audits. Implies alternative (ai_visibility_check) for single entity checks. No explicit when-not-to-use, but context is clear.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds concrete behavioral insight: partial failures degrade gracefully, bundlephobia's first measurement on a new version can take 5-30s, and sources_failed will list timeouts. This goes well beyond the annotations to set accurate expectations.

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

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

The description is dense with useful information—purpose, usage, output fields, limitations, failure behavior—all in a single paragraph. It front-loads the core purpose. While slightly long, every sentence earns its place with no redundancy. A minor truncation could improve conciseness, but it is well-structured.

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

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

Despite lacking an output schema, the description lists all key output fields (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable) and explains what happens on partial failure. For a tool that queries two external services with complex behavior, this description is remarkably complete.

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

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

Schema description coverage is 100% for both parameters (package name and version). The description does not add any new semantic detail beyond what the schema already provides. It mentions scoped packages are accepted, but that is already in the schema description. Baseline 3 is appropriate since the schema carries the load.

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

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

The description starts with a clear verb-resource-composite: 'Composite should I add this npm package to my project check in ONE call'. It explicitly states the tool fans out across deps.dev and bundlephobia and returns specific metrics. Among 27 sibling tools, none duplicate this npm ecosystem scanning function, so it is well-distinguished.

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 whenever an agent asks is X safe / popular / small or what does adding lodash cost me'. It also specifies the limitation: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly', which effectively tells when NOT to use it and directs to alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds significant behavioral details: 'BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).' 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?

A single dense paragraph of about 100 words, front-loaded with core purpose. Every sentence adds value: purpose, use case, pairing, technical details. No filler.

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

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

No output schema, but description explains return values: 'top-N passages with character offsets and similarity scores'. Covers embedding model, chunking, character limit, and truncation behavior. Complete for a semantic search tool with good annotations.

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

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

Schema coverage is 100% with descriptions for each parameter. The description adds more context: 'Pass the text you already pulled', 'Max passages to return (1-20, default 5)', and natural-language query examples. This enriches the 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 it performs semantic search inside a fetched record, with examples like SEC 10-K body. It explains the output (passages with offsets and scores). Although it doesn't explicitly differentiate from all sibling tools, the context of searching within a specific text is clear.

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

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

Explicitly states when to use: 'when the record is too big to cram into the prompt'. Provides an alternative: 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document.'

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 behavioral details beyond annotations: SMS 10/day cap, phone verification requirement, webhook auto-disable after 10 failures, and webhook signing. However, idempotentHint=true conflicts with description implying new subscription per call (not explicitly resolved).

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?

Dense single paragraph but front-loaded with purpose and key requirements. Could benefit from bullet points for readability, but 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?

Covers types, parameters, delivery options thoroughly. Lacks output schema, so minimal return value description ('Returns the new subscription id') is sufficient but missing error handling and idempotency clarification.

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 meaning: type-specific examples, delivery channel specifics (webhook HMAC signing, SMS verification), and nested parameter details. Far exceeds baseline.

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

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

Clearly states 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' Uses specific verb (create) and resource (subscription), distinguishing it from sibling tools like list_subscriptions and unsubscribe.

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

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

Provides context on authentication requirements (Pipeworx OAuth account) and lists supported types and delivery channels, but does not explicitly compare to alternatives like recent_alerts or explain when not to use this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds that it draws from a live catalog and returns structured examples, providing context 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 lengthy with many example queries and a long list of categories, which could be more concise. It is front-loaded with key uses, but contains redundant phrasing.

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

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

For a discovery tool with one optional param and no output schema, the description adequately covers purpose, usage, and output nature (category-bucketed examples). No major 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?

Parameter schema coverage is 100%; description adds meaning by listing valid topic values (finance, pharma, etc.) and explaining behavior when omitted (full spread).

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

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

The description clearly states it is an onboarding entry point that returns category-bucketed example questions with exact tool and argument shapes, distinguishing it from siblings like ask_pipeworx.

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

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

Explicitly says 'Use this FIRST' when unsure what Pipeworx can do, and describes optional topic filtering. Lacks explicit when-not-to-use, but context is clear.

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

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

Describes that the row is deactivated (not deleted) and historical events remain available via recent_alerts, adding important 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?

Two concise sentences that convey all essential information without waste. Front-loaded with the main 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 no output schema and simple tool, the description covers purpose, constraints, and side effects completely. No gaps.

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

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

Schema coverage is 100% with a clear description for the 'id' parameter. The tool description does not add additional semantics beyond what the schema already provides.

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

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

The description clearly states it cancels a subscription by id, matching the title 'Unsubscribe from Alerts'. It distinguishes from siblings like subscribe and list_subscriptions.

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

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

Specifies ownership enforcement ('you can only cancel your own subscriptions'), guiding when to use. Does not explicitly mention when not to use or list alternatives, but it's clear given the 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?

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds crucial context beyond these: the two processing pipelines (SEC EDGAR fast path vs. grounded fallback), the exact verdict values, the meaning of could_not_verify vs. unsupported, and the presence of verification_error. This is transparent about edge cases and error handling, going well beyond the structured hints.

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

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

The description is dense but well-structured, starting with trigger phrases, then usage, return values, caveats, and finally the efficiency benefit. It is longer than necessary but every part earns its place by conveying essential routing and error semantics. The structure is logical with clear sections.

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 lack of an output schema, the description fully compensates by enumerating possible verdicts, explaining the citation format, and clarifying ambiguous result states. It also addresses when to substitute other tools and notes the tool's role in reducing sequential calls. The description is sufficiently complete for an agent to correctly invoke and interpret results.

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

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

The input schema already provides complete coverage with detailed descriptions for both parameters (claim and tolerance_pct). The description adds practical guidance, such as using tolerance_pct 1-2 for hallucination detection and explaining that it overrides the claim-implied tolerance. This adds meaningful value over 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: natural-language claim verification against authoritative sources. It lists trigger phrases and explicitly distinguishes between company-financial claims and other factual claims. This is a specific verb+resource and differentiates it from sibling tools like ask_pipeworx or deep_research.

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 whenever the agent needs to check whether something a user said is factually correct,' which is clear when-to-use guidance. It also explains the routing logic for different claim types. However, it does not explicitly name alternative tools or provide when-not-to-use conditions, so it stops short of a perfect score.

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