Ipaddress

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

Annotations indicate read-only, idempotent, non-destructive; description adds detail on default model, API key usage, and per-model return structure, enriching the behavioral model.

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 cover purpose, model details, output format, and use cases, front-loaded with 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?

Despite no output schema, description clearly describes return structure (per-model score, confidence, raw response); all necessary information for usage is present.

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 descriptions cover all 4 parameters (100% coverage); description adds context like default model and API key purpose, and explains the context parameter's role in disambiguation.

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 probes LLMs for brand visibility and returns per-model scores, distinguishing it from sibling tools like deep_research or scan_competitor_ai_presence through specific output details.

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

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

Explicitly lists use cases (AI-marketing audits, pre-launch checks, competitive monitoring) but does not contrast with similar sibling tools or state 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds meaningful behavioral context: it routes to 5,501 tools, fills arguments, returns pipeworx:// citation URIs, works on every tier, and is a single fast call. It also clarifies that it can handle live news via dedicated packs. No contradiction with annotations, and the added context goes 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 longer than average but densely packed with actionable guidance. It opens with the most important directive ('PREFER OVER WEB SEARCH'), uses clear segmentation (when to use, examples, step-up criteria), and every sentence earns its place. The only minor deduction is for slightly repetitive phrasing (e.g., multiple ways to say 'use this first'), but overall 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?

Given the tool's complexity (routing across thousands of sources, many potential use cases) and the rich annotations and schema, the description is fully complete: it states the domain coverage, the underlying mechanism, the return format (structured answer with stable citation URIs), examples, and explicit escalation paths. No output schema exists, but the description clearly conveys what the agent can expect and when to choose this tool over alternatives.

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

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

Schema coverage is 100% with all parameters being aliases for 'question', and the schema already describes the field and its aliases. The description doesn't add parameter-level semantics beyond the schema, but it does provide concrete example questions ('current US unemployment rate', 'Apple's latest 10-K') which demonstrate expected inputs. Baseline of 3 applies since the schema carries the full 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 clearly states the tool's purpose: it routes factual questions to the appropriate tool among 5,501 verified sources and returns structured answers with citations. It distinguishes itself from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for specific use cases, making its role as the default entry point explicit.

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

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

The description provides explicit guidance on when to use this tool: 'PREFER OVER WEB SEARCH', 'Use whenever...', 'START HERE for most questions'. It also gives clear conditions for stepping up to more specialized tools (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions), and notes that breaking-news queries are already handled. This is exemplary usage guidance.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false), the description adds critical behavioral context: it is a full working router that falls back to nothing, the experimental nature, and the fact that active routing candidates may change behavior live. It also discloses the current state (no active candidate as of 2026-07-26) and that results are used for comparison, giving agents a clear mental model of potential variability.

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

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

The description is compact and dense, covering purpose, current state, usage, and behavior in three sentences. It front-loads the beta identity and quickly establishes equivalence to ask_pipeworx. Minor deduction for the slightly conversational 'No candidate is active right now' phrasing, but every sentence earns its place.

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

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

Given no output schema and rich annotations, the description fully covers what an agent needs: what the tool does, current behavior, how it differs from the stable version, and what to expect in terms of result comparison. It also addresses the experimental nature and fallback behavior, leaving no critical gaps for selection or 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 every parameter is aliases for the same natural-language question, which the schema already documents. The description adds value by clarifying that the tool accepts the same arguments as ask_pipeworx and the response shape is identical, but it doesn't need to restate alias mechanics. A slight deduction because the description doesn't add new semantic depth beyond confirming the argument family, though the schema handles it well.

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

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

The description clearly identifies this as the beta version of ask_pipeworx, an identical universal router with the same 5,501 tools, arguments, and response shape, but with candidate routing improvements enabled when under test. It directly distinguishes itself from siblings like ask_pipeworx and ask_pipeworx_grounded by emphasizing its role as the experimental edge.

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 it should be used exactly like ask_pipeworx when you want the newest routing, and notes that results are compared against the stable router to decide what merges. It also transparently says no candidate is active right now, so it currently matches ask_pipeworx exactly, providing clear when-to-use and current-state 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 read-only, open-world, idempotent, and non-destructive hints. The description adds substantial behavioral context: refusal reasons (not_in_source, no_tool_match, tool_error, data_truncated, llm_error), evidence extraction, exactly-once grounding in tool output, and the extra LLM call cost. No contradiction with annotations.

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

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

The description is dense and front-loaded with the core purpose. While it includes minor extravagances like exact scale figures (5,501 tools, 1,441 sources) and repeated ask_pipeworx mentions, every sentence contributes useful information. It is longer than ideal but well-organized.

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

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

With no output schema, the description compensates admirably by specifying the full success response structure and all refusal_reason enum values. It covers use cases, cost tradeoff, routing behavior, and differentiation from siblings, making the tool's behavior fully predictable for an agent.

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

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

Schema coverage is 100%: all six properties (question plus five aliases) are described and the main parameter's natural-language semantics are explicit. The description adds no parameter-specific detail beyond noting that the tool fills arguments internally, which is already implied by the schema. Baseline 3 is appropriate.

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

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

The description clearly defines the tool as a grounded, hallucination-resistant mode that routes like ask_pipeworx but extracts answers only from tool results. It distinguishes itself from the similar ask_pipeworx sibling by focusing on high-stakes verbatim/cited use cases and explicitly states the return format.

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 provides explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on' and gives the alternative 'prefer ask_pipeworx for casual lookups.' This directly addresses when not to use it and names the sibling alternative, making selection unambiguous.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds extensive behavioral context: low-confidence resolution short-circuit, closed market handling, wide spread tradeability warnings, cancellation rule parsing, news fallback mechanisms, and parent event extraction. This far exceeds annotation coverage.

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

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

The description is comprehensive but very long, covering many edge cases and details. While every sentence adds value, the length may overwhelm agents. It is front-loaded with purpose and key details, but the extensive enumeration of classifiers, fan-out examples, and response shapes could be condensed without losing clarity.

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

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

Given the tool's complexity (multiple response shapes, resolver confidence, parent events, news fallback, cancellation rules), the description covers all necessary context. No output schema exists, so the description fully explains return values and edge cases. It provides sufficient guidance for correct invocation and interpretation.

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

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

Schema covers all three parameters with descriptions. The description adds meaning beyond schema: explains depth options (quick vs. thorough), clarifies include_raw default behavior (summarized vs. full payloads), and elaborates on market input types. With 100% schema coverage and additional context, the description provides full 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 clearly states the tool researches a Polymarket bet by pulling Pipeworx data, accepts multiple input formats (slug, URL, question text), and returns an evidence packet with comparison. It distinguishes from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on research for specific bets.

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

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

Explicit use cases are given: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. Examples of fan-outs per category provide context. However, it does not explicitly exclude alternative tools or state when not to use, though the clarity of purpose implies usage boundaries.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds 'Keyless, offline', providing additional context about no external dependencies and offline operation.

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 stating the core functionality followed by two key attributes. No filler or redundancy.

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

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

Despite lacking an output schema, the description explicitly lists all computed outputs (network address, broadcast, etc.), making the tool's return values clear. Combined with annotations, the context is complete for this simple tool.

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

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

Schema coverage is 100%, with the schema describing the parameter as 'An IPv4 CIDR, e.g. "10.0.0.0/8".' The tool description adds examples but does not substantially enhance parameter meaning beyond what the schema provides.

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

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

The description clearly specifies the action ('Parse', 'compute') and the resource (IPv4 CIDR block), and lists the computed outputs. It also distinguishes itself with 'Keyless, offline', differentiating from potentially similar 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 implies usage for parsing CIDR blocks but does not explicitly state when to use this tool versus alternatives like `parse_ip`. No when-not or exclusion criteria are provided.

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, idempotentHint, etc. Description adds significant detail: data sources (SEC EDGAR/XBRL, FAERS), specific financial fields, fiscal year handling, sorting by primary metric, and citation URIs. No contradictions.

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

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

Description is detailed but well-structured. Front-loads common natural-language triggers, then explains behavior. Every sentence adds value, though slightly longer than minimal. Still efficient for the information density.

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

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

Given no output schema, description fully covers return characteristics (paired data, citation URIs, sorted results) and edge cases (fiscal year handling). Completely defines when and how to use, including claims about replacing 8–15 sequential lookups.

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 meaning: explains valid values (tickers/CIKs for company, drug names for drug), constraints (2–5 items), and how type affects data retrieved. Enriches understanding beyond schema descriptions.

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

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

Clear verb+resource: 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' Distinguishes from siblings like entity_profile or resolve_entity that do single lookups. Includes examples of triggering queries.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' Provides specific query patterns that should trigger this tool, making selection unambiguous.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context: account/paywall requirements, depth-dependent hop behavior, gap recovery, contradictions[], semantic excerpting, citation_uri fetchability, and expected latency. It also explicitly states it never invents answers ('never invented') and describes the gaps[] field.

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 quite long but dense with unique, non-redundant information. It is front-loaded with the account requirement and uses inline clarifications effectively. Some scannability is lost due to the run-on structure, but every sentence contributes operational 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 the tool's complexity and lack of an output schema, the description is remarkably complete. It covers prerequisites, alternatives, operational behavior, output structure (findings packet with evidence, confidence, source, gaps[]), error handling, citation semantics, and performance expectations. This fully compensates for the absent output schema.

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

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

Although the input schema already covers both parameters at 100%, the description adds real meaning beyond the schema. It explains the practical implications of depth values ('quick=3 (single hop)', 'standard=5... gap-recovery hop + contradictions[]', 'thorough=8... chases leads') and clarifies that the question parameter accepts broad/multi-part natural language.

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 function: 'Grounded multi-source research across Pipeworx's 1441 STRUCTURED data sources... in ONE call' and explains the mechanism (decomposes questions, routes to 5,501 tools in parallel). It explicitly distinguishes from siblings like ask_pipeworx for single lookups and breaking news, making its purpose unambiguous.

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

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

Usage guidance is explicit and actionable. It states when to use deep_research ('Best for broad/multi-part questions over structured data'), when not to use it ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'), and includes a prerequisite (account required) with an alternative for unsigned users.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: 'Returns the 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 clarifies the output format and immediate usability.

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

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

The description is a single, well-structured paragraph that front-loads the core purpose, then lists domains, explains return value, and gives usage advice. It is concise but could be slightly more compact without losing clarity.

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

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

Given the absence of an output schema, the description adequately explains what is returned (top-N tools with schemas ready to call). It covers the key aspects: what the tool does, when to use it, and the format of results. No major gaps remain.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description adds collective context about the tool's behavior (e.g., 'top-N') but does not enhance individual parameter semantics beyond the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists numerous example domains and explicitly distinguishes its role as a discovery tool among many sibling tools, making its unique value obvious.

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

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

The description provides explicit when-to-use guidance: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It does not explicitly state when not to use it, 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?

Discloses behavior beyond annotations: fans out across multiple sources, returns specific fields with details (e.g., 'recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs)'), notes patent soft-fail after May 2025, and fallback chain for news (GDELT→GNews). Annotations (readOnlyHint, idempotentHint) are consistent and augmented.

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

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

The description is front-loaded with user query examples and a strong purpose statement. It is dense but avoids redundancy; however, it could be slightly shortened by removing the patent sunset note which is time-sensitive. Still, every sentence earns its place.

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

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

Given no output schema, the description thoroughly explains return values (filings count, fundamentals sorted, patent status, news fallback, LEI). It covers limitations (names unsupported, patent sunset) and suggests resolve_entity. For a complex multi-source tool, it provides complete context for an agent.

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

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

Schema coverage is 100% and descriptions in schema are detailed (e.g., value: 'Ticker (e.g., "AAPL") or zero-padded CIK...'). The description repeats this info but adds context like 'Names not supported — use resolve_entity first.' Since schema already covers parameters well, description adds marginal value beyond examples.

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

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

The description clearly states the tool provides a 'full cross-source profile of a US public company in ONE parallel call,' listing specific data types (CIK, filings, fundamentals, patents, news, LEI) and contrasting with chaining single-pack lookups. This distinguishes it from siblings like deep_research or compare_entities.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and advises 'names not supported (use resolve_entity first if you only have a name).' This provides clear when-to-use and when-not-to-use guidance with an alternative 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 indicate destructiveHint=true and idempotentHint=true. Description adds context about clearing sensitive data, which aligns with annotations. No contradiction.

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

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

Two concise sentences with no fluff. Front-loaded with action and usage criteria.

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

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

For a simple single-parameter destructive tool with strong annotations, the description provides all necessary context: purpose, when to use, and relation to sibling tools.

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

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

Schema coverage is 100% with parameter 'key' described as 'Memory key to delete'. Description does not add extra meaning beyond schema, so baseline 3 is appropriate.

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

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

Description clearly states 'Delete a previously stored memory by key', specifying the verb (delete) and resource (memory). Distinguishes from sibling tools like 'remember' and 'recall'.

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

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

Explicitly says 'Use when context is stale, the task is done, or you want to clear sensitive data...' and mentions pairing with 'remember' and 'recall', providing clear when-to-use and alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations by explaining the fetch-extract-emit process and output format ('single text blob'). No contradictions with annotations.

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

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

The description is concise (4-5 sentences) with no wasted words. It front-loads the main action and key details, making it easy for an agent to quickly understand the tool's function.

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

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

Despite having no output schema, the description fully explains the output (single text blob in standard markdown format). Given the tool's simplicity (2 params, no nested objects), the description covers all necessary information 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%: both parameters (url, max_links) have descriptions. The description adds minimal extra meaning beyond the schema (e.g., url example), so baseline 3 is appropriate.

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

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

The description clearly specifies the tool's purpose: generate a production-ready llms.txt file for any URL to help AI crawlers index the site. It details specific actions (fetch, extract title/description/key links, emit standard markdown) and explicitly distinguishes from sibling tools like scan_competitor_ai_presence by focusing on file generation.

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

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

The description provides explicit use cases: getting a client's site indexed, drafting llms.txt for own project, auditing competitor AI visibility. While it doesn't explicitly state when not to use it, the scenarios are clear and sufficient for an agent to decide when this tool is appropriate.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds return fields and clarifies active-only behavior, extending 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 with front-loaded purpose and return fields. 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?

With no output schema, description lists return fields adequately. No mention of pagination, but for a simple list this is likely sufficient. Annotations cover behavioral safety.

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

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

Schema coverage is 100% with clear description for 'include_inactive'. Description does not add further parameter detail, 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?

Clearly states 'List the caller's active subscriptions,' specifying verb and resource. Distinct from sibling tools like subscribe and unsubscribe.

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

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

Provides practical guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Implicitly tells when not to use (when you want to subscribe/cancel).

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. The description adds 'Keyless, offline' and details on output classification, providing extra behavioral context.

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

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

Two concise sentences pack key information: validation, classification, return values, and operational characteristics (keyless, offline). No wasted words.

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

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

Given the single parameter, no output schema, and clear annotations, the description fully covers what the tool does, what it returns, and that it requires no authentication or network.

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

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

Schema coverage is 100% and the parameter description in schema is sufficient. The tool description adds no additional meaning to the parameter beyond what schema provides.

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

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

The description clearly states the tool validates and classifies IP addresses (IPv4/IPv6), specifying version, validity, classification types, and integer return for IPv4. It is distinct from siblings like cidr_info.

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 implies usage context with 'Keyless, offline' but does not explicitly state when to use vs alternatives. However, no sibling tool overlaps, and the context is clear.

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

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

Annotations provide no behavioral hints (all false), so the description carries the burden. It transparently explains the token flow ('Filing without an account returns a claim_token; pass it back later...to read whether it was fixed'), rate limiting ('Rate-limited to 5 per identifier per day'), and cost ('Free; doesn't count against your tool-call quota'). It also indicates the impact ('The team reads digests daily and signal directly affects roadmap').

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

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

The description is dense but every sentence serves a purpose. It front-loads the purpose, then flows into when-to-use, scope boundaries, message guidelines, token mechanics, and operational details—all in a logical sequence. Nothing is redundant or extraneous given the tool's complexity.

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

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

The tool has 4 parameters, a nested object, and no output schema, but the description covers all behavioral and invocation nuances. It explains the return value implicitly (claim_token), rate limits, cost, and the intended audience. This is a fully specified description for an agent to correctly select and call the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful value by showing how the claim_token is used in practice: 'pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})'. It also provides content guidance for the message and context fields: 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt.' This goes beyond the schema's per-field descriptions.

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

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

The description opens with a specific action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clarifies the resource (Pipeworx team) and enumerates the exact feedback categories. It also sets boundaries by distinguishing from sibling tools that ask questions or discover tools, making it uniquely positioned as the feedback channel.

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

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

Explicit guidance is given: '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 provides an exclusion—tools from other MCP servers should be reported elsewhere—and suggests an alternative action: 'file it with that server instead.' This fully covers when and when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral details: no PII, aggregated from CF analytics-engine, cached 5min-1h, and self-aggregating nature. 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?

Concise yet comprehensive: opens with the core function, then lists use cases in a bullet-like fashion, and ends with data source and caching details. Every sentence serves a purpose 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 read-only tool with one optional parameter and no output schema, the description covers return contents, window semantics, use cases, data source, privacy, and caching. No gaps remain.

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

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

Schema coverage is 100% with a single enum parameter. The description adds nuance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This aids selection 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 returns trending data (top tools, packs, call volume) over configurable windows. It distinguishes itself from sibling tools by focusing on popularity trends rather than specific searches or profiles.

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 provided (discovering hot data, confirming canonical tools, aligning use cases). The window parameter description also guides selection between short and long-term trends. No explicit when-not-to-use, but sufficient 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 a read-only, idempotent, non-destructive tool. The description adds extensive behavioral context: it walks child markets, checks ordering, computes partition sum with deviation threshold, applies semantic similarity and placeholder filtering, and includes fill check logic with realizable edge limits. This fully discloses operational nuances.

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

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

The description is relatively long but well-structured, starting with the overall purpose, then detailing call modes, followed by technical specifics. Every sentence adds value, though some details (e.g., fill check) could be slightly condensed without losing clarity.

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

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

Despite no output schema, the description thoroughly explains the response structure (opportunities array with fields, partition_check object in event mode) and conditions under which trades should be avoided (realizable edge <= 0). It also references a related tool for custom sizing, leaving no gap for a complex tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description enriches these by providing examples (slugs, seed questions), noting URL acceptance for event, and explaining behavioral differences. This adds value beyond the schema, though the schema descriptions are already adequate.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three call modes (trending scan, event, topic) and differentiates from sibling tools like polymarket_fill_risk by mentioning fill check and custom sizing.

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

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

The description provides explicit guidance on when to use each argument: no args for trending scan, event for specific market, topic for cross-event scanning. It explains the benefits of each mode and when one might catch patterns the other misses, enabling informed 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?

The description adds substantial behavioral context beyond annotations: 1-hour KV caching, three response segments with full model details, diagnostic output for debugging empty segments, and specific filtering gates. All annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent and reinforced by the description's read-only, non-destructive nature.

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

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

The description is dense and comprehensive but lacks conciseness. It front-loads the purpose but then includes extensive technical details about model families and parameters that could be condensed or structured more clearly. While thorough, it is longer than necessary for quick agent comprehension.

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 tool with 9 optional parameters and no output schema, the description covers response structure (by_segment, diagnostics), key fields (edge_pp_net, kelly_fraction), caching behavior, and model details. It omits a formal return schema but provides sufficient context for an agent to understand and use the tool effectively.

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

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

Schema coverage is 100% with detailed per-parameter descriptions. The tool description adds value by grouping parameters into 'Tradeable-Edge Knobs' and explaining nuanced behavior like min_partition_leg_kelly's interaction with partition arbs. This contextual grouping enhances understanding beyond the schema alone.

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

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

The description clearly states it scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, specifically for the 'what should I bet on today' use case. It distinguishes itself from related tools like polymarket_arbitrage by detailing its unique model families and filtering logic.

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

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

The description provides strong context on when to use (daily discovery of opportunities) but lacks explicit when-not-to-use guidance or direct alternatives among sibling tools like polymarket_arbitrage or polymarket_edge_tracker. It implies usage through the 'what should I bet on today' framing but does not explain when other tools would be more appropriate.

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 beyond annotations (readOnlyHint, idempotentHint) by detailing the response structure, the meaning of decay_pp_per_day (absolute value, signed), the 60-day snapshot TTL, and snapshot write conditions. 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 dense but well-structured: purpose, then the response format with arrays, then limits. It is slightly verbose but each sentence adds meaningful information.

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

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

Despite no output schema, the description fully explains the response structure (tracked[], expired[], snapshot_dates[]) and the limits (60-day snapshot TTL, snapshot conditions). It covers defaults and constraints for both parameters, making the tool usage complete.

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

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

Schema coverage is 100%, but the description adds context by specifying default values (days:14, window:'1wk'), valid ranges (days clamped 2-30), and possible window values (24hr, 1wk, 1mo). This adds value beyond the schema alone.

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

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

The description clearly states the tool's function: tracking edge persistence and decay over time using daily snapshots. It specifies the output fields (tracked, expired, snapshot_dates) and distinguishes from the sibling tool 'polymarket_edges' which likely provides current edges only.

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 implies when to use this tool versus alternatives by contrasting 'fresh wide edge' with '3-week-old wide edge'. It provides context for decision-making but does not explicitly name alternative tools or say when not to use.

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

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

Adds significant context beyond annotations: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.) and warns about partial fill risks. 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?

Well-structured with clear mode separation and labeled sections. Slightly long but every sentence adds value, making it acceptable given 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?

Fully explains both modes, all parameters, output fields, and usage context. No output schema, yet description is comprehensive enough for an agent to understand behavior.

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 meaning: clarifies size_usd interpretation per mode, and side auto-default from partition sum. Provides extra context above schema.

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

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

Clearly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' with two modes (single-market and basket). Distinguishes from siblings like polymarket_arbitrage and 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: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Explains why (theoretical overround not capturable, partial fills convert arb to directional risk).

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?

Goes beyond annotations by explaining compatibility scenarios, temporal alignment checks, skipped cross types/subtypes, and when spreads are meaningless. No contradiction with readOnlyHint or idempotentHint.

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

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

Well-structured with clear sections (concept, modes, response, safety fields). Slightly verbose but justified by the tool's complexity. Front-loads the core purpose.

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

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

Comprehensive for a tool with no output schema: explains input modes, output fields (leg-by-leg prices, spread, compatibility_warning, temporal_alignment, skipped counters), and edge cases. Fully compensates for missing output schema.

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

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

Schema has 100% coverage, but description adds context: examples for topic, explanation that explicit params override topic-mapped sides, and detailed response fields. Provides meaning 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?

The description clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It specifies two modes (topic shortcuts and explicit tickers) and describes the output, distinguishing it from sibling tools like polymarket_arbitrage.

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

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

Explicitly describes when to use each mode (topic for predefined macros, explicit for custom pairings). Includes warnings that most pre-mapped topics currently return compatibility warnings, advising that pre-mapped does not mean tradeable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping info: 'Scoped to your identifier (anonymous IP, BYO key hash, or account ID).' No contradictions.

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

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

Three sentences, front-loaded with main action. Each sentence adds value: purpose, usage, scoping/pairing. 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 read tool with complete schema and annotations, description fully explains behavior, scoping, and relationships with siblings. 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%. Description adds that omitting key lists all keys, explaining optional behavior beyond schema. Also provides examples in schema.

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

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

Description clearly states the verb 'retrieve' and 'list', resource 'value previously saved via remember' or 'all saved keys', and distinguishes from siblings by mentioning pairing with remember and forget.

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

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

Explicitly states use case: 'look up context the agent stored earlier... without re-deriving it from scratch.' Mentions pairing with remember and forget, but lacks explicit when-not-to-use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. Description adds behavior about mark_read affecting subsequent calls and return fields. No contradictions.

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

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

Three concise sentences, front-loaded with main action, 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 list tool with no output schema, description explains return fields and provides alternative access. With 5 optional params, it covers key usage points.

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 context for mark_read (flags returned events read) but does not mention unread_only parameter. Schema descriptions are sufficient.

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, returning recent alerts with specific fields (source, citation_uri, payload). Distinguishes from siblings like list_subscriptions which lists subscriptions, not alerts.

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

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

Describes filtering by type and since, mentions polling is fine, and notes alternative HTTP endpoint. Does not explicitly state when not to use, but provides clear usage 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 set readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context beyond these: fan-out to SEC EDGAR, GDELT→GNews fallback, USPTO (with noted soft-failure), and the structured return format (changes[] grouped by source, total_changes, citation URIs). This level of detail helps the agent understand side effects and limitations without contradicting annotations.

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

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

The description is relatively long but every sentence adds meaningful detail. It front-loads the purpose with common user queries, followed by source details, parameter formats, and sibling guidance. While it could be slightly more concise, the structure is clear and easy to scan. The length is justified by the tool's complexity (multiple sources, fallback logic).

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 compensates by stating the return structure (changes[] grouped by source, total_changes count, citation URIs). It covers all parameters, usage context, source behavior, and fallback logic. The only minor gap is that it does not elaborate on the exact shape of each change object, but the overview is sufficient for most agents to decide whether to invoke the tool.

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

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

With 100% schema coverage, the baseline is 3, but the description adds extra meaning: for 'since', it explains acceptable formats (ISO date, relative shorthand) and recommends a typical value ('30d' or '1m'). For 'value', it provides examples (ticker or CIK). For 'type', it clarifies that only 'company' is supported. This contextual guidance goes beyond the schema descriptions.

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

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

The description immediately lists example user queries ('What's new with X', 'latest on Y'), making the tool's purpose unmistakable. It clearly states it returns a change feed for a company in a time window, fanning out to multiple sources. The explicit differentiation from sibling tool entity_profile ('Use entity_profile instead when you want the static profile') ensures the agent can distinguish it correctly.

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

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

The description provides clear context for when to use the tool (for recent changes/news) vs. entity_profile (static profile). It gives example queries and explains the multi-source fan-out and fallback behavior (GDELT→GNews). While it does not list explicit when-not-to-use scenarios, the sibling distinction and parameter guidance ('Use "30d" or "1m" for typical monitoring') are sufficient for most cases.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description supports with no contradiction. The description adds valuable behavioral context about persistence scoping and retention duration (authenticated persistent, anonymous 24h), going 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 four sentences long, front-loaded with the primary action and purpose. It is clear and every sentence adds value (purpose, use case, retention behavior, sibling references). Could be slightly trimmed by combining sentences, but overall efficient.

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

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

For a simple key-value store without an output schema, the description adequately explains return behavior (implicitly, the stored value). It mentions pairing with recall/forget and retention details. However, it omits potential error conditions (e.g., key too long, storage limit) and does not describe the response format.

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

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

Schema coverage is 100%, so the schema already fully documents the two parameters. The description reinforces their purpose with examples ('subject_property', 'target_ticker') but adds no additional syntax or constraints 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 starts with a specific verb ('Save') and resource ('data'), clearly stating the tool's role. It provides examples (resolved ticker, user preference) and distinguishes it from siblings 'recall' and 'forget', making the 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?

Explicitly advises using the tool 'when you discover something worth carrying forward' to avoid repeated lookups. It also mentions pairing with recall and forget, providing good context. However, it does not explicitly mention scenarios where this tool should not be used.

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 behavioral context beyond this: it 'cascades through several lookup endpoints internally', provides 'auto-disambiguated' input handling, and returns citation URIs. This complements the annotations without contradicting them.

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

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

The description is longer than average but every sentence adds value: examples, usage guidance, and supported types are richly detailed. The 'SUPPORTED TYPES' section is well-organized. It could be tightened, but the length is justified by the tool's dual-type complexity.

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

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

Despite having no output schema, the description explains return values, citation formats, and input disambiguation for both entity types. It also explains the internal cascading behavior. Given the tool's complexity, this description makes the tool effectively self-contained for an agent.

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

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

Even though the input schema covers 100% of parameters, the description adds substantial meaning: it explains accepted input formats for 'value' (ticker, CIK, name for company; brand/generic for drug) and what the output will include (ticker/CIK/company_name for company; RxCUI/ingredient/brand for drug). This goes well beyond the schema's terse parameter 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 resolves a name to a canonical identifier, with specific examples ('What's the ticker for…'). It distinguishes from siblings by noting other tools require these identifiers as input. The verb 'resolve' plus resource types ('company', 'drug') makes the purpose unmistakable.

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

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

Explicitly says 'Use FIRST whenever you have a name but need an ID', giving a clear when-to-use directive. It also mentions the tool replaces 2-3 manual lookups. However, it doesn't explicitly state when not to use it or name alternative tools, so it earns a 4 rather than a 5.

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

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

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), description adds that it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, signal density. It also notes the first entity is treated as subject for narrative. No contradictions with annotations.

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

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

Three sentences with no wasted words. Front-loaded with primary action and result. Structure is clear and easy to parse.

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

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

For a moderately complex tool with 4 parameters, full schema coverage, and descriptive annotations, the description covers the return format, internal behavior, and usage context. No gaps for an agent to misuse the tool.

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

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

Schema description coverage is 100% with all four parameters described. The description adds extra context: first entity is treated as 'subject' for narrative and the rest as competitors, and omitting models defaults to workers-ai. This adds meaningful guidance 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 the tool compares AI visibility across multiple entities side-by-side, ranks them, and surfaces most/least recognized. It uses specific verbs ('compare', 'probes', 'ranks') and distinguishes from sibling tool ai_visibility_check which likely operates on 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?

Description provides clear context: 'useful for competitive AI-marketing audits' and an example question. However, it does not explicitly state when not to use this tool versus alternatives like ai_visibility_check for single entity checks, leaving the agent to infer.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds important behavioral details: partial failures degrade gracefully, sources_failed list indicates failed sources, and bundlephobia first measurement can take 5-30s.

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

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

The description is well-structured and front-loaded with the core purpose, but contains some detailed return value explanations that could be slightly trimmed. It is informative without being overly verbose.

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 fully explains the return structure (summary block, per-advisory, links, alternatives). It covers ecosystem scope, failure behavior, and timing, making the tool's usage and results clear.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that scoped packages (e.g., '@types/node') are accepted and version defaults to latest, which aids correct usage.

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

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

The description clearly states the tool is a composite check for evaluating npm packages, specifying the verb 'scan' and resource 'dependencies'. It distinguishes from siblings by noting it covers NPM ecosystem only, referencing alternatives for other ecosystems.

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 agents ask about safety, popularity, or cost of adding a package. Provides exclusions (NPM only, direct deps.dev for others) and notes limitations like bundlephobia delays.

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 embedding model (BGE-base-en), window size (500-char overlapping), char cap (200K with truncation flag), and return format (passages with offsets and scores). Adds significant detail beyond annotations (readOnly, idempotent, etc.) which already indicate safe, repeatable operation.

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

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

Well-structured: purpose, benefits, pairing, technical details. Front-loaded with key info. Slightly verbose with extra examples, but clear and efficient overall.

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

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

No output schema exists, but description fully explains return (top-N passages with offsets and similarity scores). Covers all relevant behavioral aspects without requiring 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% with good descriptions. The description adds query examples and reiterates the text limit, but does not provide critical new information beyond what the schema already conveys. Baseline 3 is appropriate.

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

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

Clearly states it performs semantic search inside a fetched record, with examples (SEC 10-K, article). Distinguishes from siblings like ask_pipeworx_grounded by specifying 'inside a fetched record' and 'returns passages with offsets.'

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

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

Explicitly says when to use: when the record is too big to fit in the prompt. Suggests pairing with ask_pipeworx_grounded and contrasts with fetching 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?

Annotations indicate non-read-only, idempotent, non-destructive. The description adds context: authentication needs, delivery channel details (SMS cap, verification), and return of subscription id. No contradictions.

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

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

The description is a single paragraph that front-loads the core purpose, then provides necessary details. It is well-structured but slightly long; compactness could be improved.

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 (3 params, nested objects, no output schema), the description covers purpose, return value, prerequisites, supported types with examples, and delivery channel constraints. It is mostly complete, though could mention error 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?

Schema description coverage is 100%, so baseline is 3. The description adds examples for params (e.g., sec_8k with items) and delivery constraints (SMS cap, webhook signing) that go beyond the schema descriptions.

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

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

The description clearly states 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' It uses a specific verb and resource, and distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

The description explains when to use (creating a subscription), requirements (Pipeworx OAuth account), and limitations (anonymous/BYO cannot persist). It does not explicitly contrast with siblings, but the context of creation vs listing/deletion is clear.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context by specifying that returns include exact tool+argument shapes and explains the behavior of calling with no arguments vs a topic, going beyond annotations.

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

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

The description is front-loaded with synonyms and usage intent, then explains return value and parameters. While somewhat lengthy, every sentence adds value and the structure is logical. Minor room for 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?

With no output schema, the description adequately explains the return value (category-bucketed example questions with tool shapes) and how it works (drawing from live catalog). This fully addresses what an agent needs to know for an onboarding tool.

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

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

Schema coverage is 100% with a single parameter description. The description adds value by explaining the default behavior (full spread) and the effect of passing a topic, plus listing valid topic values, providing 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 identifies the tool as the onboarding entry point for Pipeworx, listing various synonymous queries and explicitly stating it returns category-bucketed example questions. It distinguishes itself from siblings by being the first tool to use when the agent doesn't know capabilities, and mentions related meta-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 advises to use this tool FIRST when uncertain about Pipeworx capabilities, and explains how to pass a topic for focus. While it doesn't explicitly list when not to use it, the guidance is clear and practical.

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

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

Discloses that the row is deactivated not deleted, aligning with annotations (destructiveHint=false, idempotentHint=true). Adds context beyond annotations: explains impact on historical data and idempotency, no contradictions.

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

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

Two sentences with no wasted words. First sentence defines action, second explains behavioral implications. Well structured and front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description covers all necessary aspects: purpose, usage context, behavioral details, and parameter origin. 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 covers 100% of parameters (single 'id' field). Description adds value by stating the id is 'returned by subscribe,' which clarifies the parameter's source and relationship to another tool.

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

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

The description clearly states 'Cancel a subscription by id,' using a specific verb and resource. It distinguishes itself from sibling tools like 'subscribe' and 'list_subscriptions' by focusing on cancellation.

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

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

Explicitly mentions ownership enforcement, guiding when the tool is appropriate. Also explains that historical events remain via recent_alerts, hinting at an alternative. Could be more explicit about when not to use, but clear enough.

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

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

Annotations already list readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral details: two processing paths (structured SEC for financial, grounded pipeline for others), return format with verdict and citation, and efficiency gains (replaces multiple calls). Adds meaningful 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?

Description is somewhat lengthy but well-structured: example queries, conditional logic, return values. Every sentence adds information; no redundancy. Could be slightly more concise, but maintains clarity.

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

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

Despite having no output schema, the description fully explains return values (verdict list, actual value with citation, reasoning). Covers all parameters, distinguishes claim types, and notes fallback behavior. Completeness is excellent given tool 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?

Both parameters are fully described in schema (100% coverage). Description adds value: explains claim as natural-language, tolerance_pct overrides implied tolerance, notes default behavior (capped at 5%). For a tool with full schema coverage, this is above baseline.

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

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

Description starts with clear natural-language examples ('Is it true that…', 'fact check'), specifies it verifies claims against authoritative sources, and distinguishes between company-financial and other claims with different methods. It also notes it replaces 4-6 sequential calls, making the purpose highly specific and differentiated from siblings.

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

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

Explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' Provides guidance on claim types (financial vs other) and behavior. Lacks explicit statements on when not to use, but context is clear enough.

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