Jwt

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds beyond this by detailing return structure (per-model score, confidence, signals, raw_response + combined view), cost implications of using Anthropic, and default model behavior. No contradictions.

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

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

The description is three sentences, front-loaded with the primary action and scope. Every sentence serves a purpose: stating the function, explaining defaults and API key usage, describing output, and listing use cases. No wasted words.

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

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

Despite lacking an output schema, the description sufficiently describes the return structure. All parameters are explained in both schema and description. The tool's complexity (multiple models, optional API key, scoring) is adequately covered. No missing information.

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%, providing baseline meaning. The description adds value by explaining default model selection, the role of _apiKey for Anthropic probing, and how context helps disambiguate entities. This extra information 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 uses specific verbs ('probe', 'score') and clearly identifies the resource ('LLMs for what they know about a business/brand/product/topic'). It differentiates from siblings like 'scan_competitor_ai_presence' by focusing on general visibility scoring across models.

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

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

Explicitly lists use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains when to use the optional parameters (models, _apiKey, context). Lacks direct comparison to sibling tools but context from sibling names and the description itself implies appropriate usage.

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

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

The annotations already establish read-only, idempotent, open-world behavior. The description adds meaningful behavioral detail: it routes to 5,798 tools, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. It does not contradict the annotations and provides useful context beyond 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 earns its length with domain lists, trigger phrases, examples, and sibling-tool routing guidance. Front-loading 'PREFER OVER WEB SEARCH' makes the key decision immediately. Minor redundancy exists in the overlapping phrases about authoritative data and web-search comparison.

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 broad scope, the description provides sufficient context: what it queries, how it answers, what citations look like, when to use it, and when to use alternatives. With no output schema, the description's mention of structured answers and stable citation URIs covers the essential return-value information.

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 six parameters documented as aliases for the natural-language question. The description reinforces the intended input through examples and trigger phrases, but adds little new semantic meaning beyond what the schema already states.

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 ask_pipeworx as a router that sends factual questions to the correct tool across thousands of verified sources and returns structured answers with citations. It distinguishes itself from web search and sibling tools like ask_pipeworx_grounded and deep_research through explicit use-case boundaries.

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

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

The description explicitly says to prefer this tool over web search, lists concrete trigger phrases and domain examples, and names alternative tools for data-heavy analysis, broad multi-part questions, and breaking-news sentiment. This leaves little ambiguity about when to select 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?

Beyond the readOnly/idempotent annotations, the description discloses that routing improvements are live whenever under test, that no candidate is currently active, and that it is a full working router rather than a fallback to the stable version. This accurately sets expectations for behavior that may change between calls.

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?

Each sentence carries distinct information: beta status, current equivalence, usage intent, comparison purpose, and the full-router clarification. It is slightly longer than strictly necessary, but the beta-vs-stable nuance and no-active-candidate status justify the length.

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

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

For a router with no output schema, the description tells the agent what the tool is, how to invoke it identically to ask_pipeworx, what is currently active, and that the response shape is the same. It could add a concrete response-format pointer or an explicit 'prefer stable ask_pipeworx when consistency matters most,' but nothing critical is missing.

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

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

Schema coverage is 100% and the schema already documents all aliases (q, text, input, query, prompt) and the required question parameter. The description adds only 'same arguments' as ask_pipeworx, which is helpful context but not necessary; baseline 3 applies.

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

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

The description clearly states that this is the beta version of ask_pipeworx, a universal router over 5,798 tools with the same arguments and response shape. It explicitly distinguishes itself from ask_pipeworx as the experimental candidate-routing variant, so sibling differentiation is achieved.

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 usage context: use it exactly like ask_pipeworx when you want the newest routing, and notes that it currently matches ask_pipeworx because no candidate is active. It doesn't explicitly say 'prefer the stable ask_pipeworx for production-critical work,' but the beta framing and comparison-to-stable behavior make the intended use clear.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: it discloses the extraction constraint ('ONLY what the tool result contains'), the exact refusal-reason taxonomy, the success return shape, and the cost difference. It does not describe rate limits, but the explicit refusal behavior and return contract are strong additions.

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 information-rich, but it is one long block without paragraph breaks. It front-loads the key behavioral distinction ('hallucination-resistant'), then packs routing, return contract, refusals, usage guidance, and cost comparison into a single run-on passage. Every sentence earns its place, but the structure could be improved for scanability.

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 question-answering tool with a single required parameter fully covered by the schema, read-only/idempotent annotations, and a detailed return contract (including refusal reasons), the description is complete. It also explains the cost/benefit tradeoff relative to the sibling, which is exactly the contextual distinction an agent needs to select correctly.

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

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

Schema description coverage is 100%, so the input schema already documents the parameter well, including aliases. The description adds the semantic nuance that this is a grounded question-answering mode, but it does not need to describe the parameters because the schema fully covers them. Baseline 3 applies.

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

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

The description states a specific verb ('answer'), a resource (Pipeworx tool routing), and a distinctive behavior ('grounded' extraction using ONLY tool results, with explicit refusal). It also distinguishes itself from ask_pipeworx by naming the sibling and the difference between them.

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

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

The description tells the agent exactly when to use this mode: high-stakes reads where answers will be quoted/cited/acted on, with examples of high-stakes domains (financial, legal, medical, public statements). It also gives an explicit preference: prefer ask_pipeworx for casual lookups, and notes the cost tradeoff (one extra LLM call).

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds extensive behavioral context: resolver contract with match confidence and alternatives, parent event extraction, news fallback mechanisms, safety short-circuits for low-confidence matches, closed market handling, illiquid spread warnings, and resolution-rule risk parsing. 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 quite long (several paragraphs) and contains many details. While the first sentence gives the main purpose, the density of information makes it somewhat verbose. The length is justified by tool complexity but still could be more concise.

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

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

Given the tool's complexity and lack of an output schema, the description is remarkably complete. It covers response shapes, resolver behavior, parent events, news error handling, safety conditions, closed markets, liquidity warnings, and cancellation rule parsing—all essential for correct usage.

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

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

Schema coverage is 100% with three parameters described. The description adds context beyond the schema: market accepts multiple formats (slug, URL, question), depth enum explained, include_raw's impact on response size. This provides meaningful additional guidance.

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

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

The description clearly states 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input types (slug, URL, question text) and output (evidence packet + comparison). It distinguishes from sibling tools like polymarket_edges and polymarket_arbitrage by stating use cases 'should I bet on X', etc.

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

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

Explicit usage guidance: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' Context on depth parameter (quick/thorough) is given. No explicit when-not or alternatives, 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?

Beyond annotations (readOnlyHint, idempotentHint), the description reveals that calls are parallel, off-calendar fiscal years are handled, results sort by primary metric, and output includes paired data with citation URIs. This adds meaningful behavioral context.

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

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

The description is compact at 4 sentences, front-loaded with examples, and each sentence adds distinct information. It could be slightly more structured (e.g., bullet points), but it efficiently conveys the tool's purpose and behavior.

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 (comparing multiple entities with two types), the description covers purpose, when to use, data sources, sorting, and output format (paired data + citation URIs). Lacking explicit output schema details, but the information provided is sufficient for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining that 'values' for companies are tickers/CIKs and for drugs are names, and clarifies that 'type' determines the specific data pulled (financial vs. FAERS). This surpasses 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 starts with explicit query examples and states it provides side-by-side comparison of 2–5 companies or drugs. It clearly distinguishes from sequential single-pack lookups, supported by the sibling tool 'entity_profile' which handles single 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?

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and gives context for when to use (comparing, ranking, head-to-head). It does not specify when not to use, but the preference statement effectively guides the agent.

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

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

The description adds value beyond annotations by stating it is keyless, offline, and lists output specifics (header, payload, ISO date claims, expiration check). The annotation contradiction is false. It clearly describes behavior 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 concise with two sentences plus a critical note. It is front-loaded with the main action and output, followed by an important caution. No unnecessary words.

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

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

The description adequately covers the tool's purpose, output, and limitations despite no output schema. It mentions the output content (header, payload, summary) and expiry check. Missing details about error handling are minor for a simple decode 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 'token' parameter described. The description does not add extra detail about the parameter beyond the schema, so a baseline 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 title and description clearly state the verb 'decode' and resource 'JWT'. It specifies what is returned (header, payload, summary of claims) and distinguishes from siblings by its unique function. No other sibling tool decodes JWTs.

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 notes that the tool decodes but does NOT verify the signature, guiding the agent to use it for inspection only and not for trust verification. It implies appropriate usage contexts (offline, keyless) without alternatives needed due to no similar tools.

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

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

The description adds a wealth of behavioral context beyond what the annotations (readOnlyHint, openWorldHint, idempotentHint) provide: parallel facet decomposition, explicit gaps[] with a 'never invented' guarantee, gap-recovery hops per depth, contradictions[] scanning, semantic excerpting of large records ('not head-truncated'), resolvable citation_uri semantics, latency expectations (15-60s, up to ~90s for thorough), and auth/tier gating. No contradiction with annotations — 'never invented' and grounded sourcing are consistent with readOnlyHint=true.

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

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

Every sentence earns its place — there is no filler — and the critical routing information (account required, use ask_pipeworx if not signed in, not open-web search) is front-loaded. However, the prose is structurally sprawling: heavily parenthetical run-ons and em-dash chains (the opening sentence alone packs three distinct facts) make the details harder to parse than necessary. The length is justified for a tool this complex, but tighter formatting would improve scannability.

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

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

With no output schema, the description fully carries the burden of explaining return values, and it does so thoroughly: the findings packet shape (verbatim evidence + confidence + source + fetched_at + pipeworx:// citation), the hop field and citation_uri guarantee, gaps[] and contradictions[] behavior, and the semantic-excerpting behavior for large records. It also covers latency, auth tiers, and what the tool is not. Only minor omissions exist (rate limits, exact unauthenticated error behavior), but for a tool of this complexity the coverage is exceptional.

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

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

Schema coverage is 100%, so the baseline is 3 with the schema doing the heavy lifting. The description goes beyond the schema by enriching the depth parameter with behavioral meaning: what each level actually does (gap recovery, chasing leads from the first pass), the paid gating for thorough, and the latency implications. It also clarifies what kinds of questions the question parameter is suited for ('Broad/multi-part is fine'). This is genuine added value, not schema repetition.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources... in ONE call.' It explains the mechanism (decomposes into facets, routes in parallel to 5,798 tools) and explicitly differentiates itself from siblings: 'this is NOT open-web search' and 'For a single lookup use ask_pipeworx.' An agent can clearly tell this apart from ask_pipeworx and the other research-related siblings without opening schemas.

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

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

The description gives explicit when-to-use and when-not-to-use guidance with named alternatives: use when signed in and dealing with 'broad/multi-part questions over structured data' with concrete examples ('compare X and Y's regulatory + financial exposure'); use ask_pipeworx for single lookups and for unauthenticated users ('If you are not signed in, use ask_pipeworx instead — it works on every tier'). This is textbook routing guidance — nothing is left to inference.

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

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

Annotations declare readOnlyHint, destructiveHint, idempotentHint; the description adds that it returns full input schemas with curated examples ready to call directly. No contradictions. The description enriches understanding beyond annotations.

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

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

The description is front-loaded with the core purpose. Every sentence adds value: specifying use cases, listing data domains, explaining the return format, and strategic advice. It is dense but not 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?

For a discovery tool with no output schema, the description adequately explains what is returned (names, descriptions, schemas). It covers the tool's role in the workflow, making it complete for an agent to understand and invoke.

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 that query accepts multiple aliases (task, q, description, search) and clarifies the intent of the query parameter as a natural language description. This adds value beyond the schema.

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

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

The description clearly states that the tool finds tools by describing a data or task, and returns top-N relevant tools with full schemas. It distinguishes itself from sibling tools by positioning it as the first tool to call when many are available.

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

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

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for...' and lists many domains. Also advises 'Call this FIRST when you have many tools available and want to see the option set.' This provides clear when-to-use guidance.

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

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

Beyond the read-only/idempotent annotations, it discloses fan-out sources, soft-failure behavior for USPTO, that empty sections mean real 'no data', returned resolved:false with notes for private companies, and source_used/source_failed reporting. This gives an agent a reliable model of side effects and failure modes.

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

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

The description is front-loaded with purpose and usage, then organized into return fields, sources, and input shapes. It is long and occasionally repeats schema text ('names now resolve via SEC EDGAR'), but the density and semicolon-separated structure keep it usable.

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 still enumerates the main return fields, lists the data sources, explains partial failure semantics, and covers all accepted input forms and the unresolved-company case. Nothing needed to invoke it correctly for a US public company is missing.

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

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

The schema already covers both parameters at 100%. The description adds useful semantics: zero-padded CIK, SEC EDGAR name resolution, private-company unresolved behavior, and that type is interchangeable. These clarifications go beyond the schema without repeating it verbatim.

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

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

The description uses a specific action ('full cross-source profile') plus a clear resource ('US public company') and illustrates with concrete user intents like 'brief me on Tesla' and 'company profile for Microsoft'. It also distinguishes itself from 'chaining single-pack SEC/XBRL/news lookups', making its holistic role clear even among 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?

It explicitly states when to prefer this tool ('when the user asks for a holistic view' and example phrasings) and says to prefer it over chaining single-pack lookups. It does not name sibling tools like resolve_entity or compare_entities as alternatives, so the when-not guidance is less explicit than ideal.

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 destructiveHint=true and idempotentHint=true. The description adds context ('previously stored memory', 'clear sensitive data') but does not reveal significant additional behavioral traits beyond what annotations convey.

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

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

Two sentences, front-loaded with the action, no wasted words. Efficiently conveys purpose and usage.

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 one-parameter tool with no output schema and clear annotations, the description fully covers its purpose, usage, and relation to siblings. No gaps identified.

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

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

Schema coverage is 100% with one parameter ('key') described as 'Memory key to delete.' The description adds 'by key' which mirrors the schema, providing no extra meaning. Baseline 3 is appropriate.

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

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

The description clearly states 'Delete a previously stored memory by key,' specifying the verb (delete) and resource (memory). It distinguishes from siblings by mentioning pairing with 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?

Provides explicit when-to-use scenarios: stale context, task completion, clearing sensitive data. Missing when-not-to-use guidance, but the context is clear and pairs well with siblings.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral detail: it 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' No contradictions and the added context clarifies the tool's exact 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 concise (4 sentences) and front-loaded with the main action. Every sentence adds value: definition, process steps, and usage contexts. No extraneous information, well-structured.

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

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

Despite having no output schema, the description explains the output format ('standard llms.txt markdown format', 'single text blob ready to drop at site-root/llms.txt'). With low complexity (2 params, no nested objects), this covers all essential 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 description coverage is 100%, with both parameters ('url' and 'max_links') already well-described in the schema. The description does not add additional semantics beyond what the schema provides, so baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: 'Generate a production-ready llms.txt file for any URL'. It specifies the verb (generate) and resource (URL), and distinguishes from siblings by mentioning AI crawlers and the specific output format. This is highly specific and actionable.

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

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

The description explicitly lists use cases: 'getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.' It provides clear context for when to use the tool, though it does not directly compare to sibling tools or exclude scenarios.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds value by specifying that it returns the caller's own subscriptions and listing the exact fields returned, which helps the agent understand the response shape.

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 wasted words. Each sentence serves a purpose: what it does and when to use it.

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

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

Given the tool's simplicity (one optional boolean parameter, no output schema, clear annotations), the description covers the essential aspects: purpose, returned fields, and usage context. It is complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100% (one parameter fully described in schema). The description does not add extra meaning beyond the 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?

The description clearly states "List the caller's active subscriptions" and enumerates the returned fields (id, type, params, created_at, last_fired_at, fire_count). It distinguishes from siblings like subscribe and unsubscribe by focusing on listing active subscriptions.

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

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

The description provides explicit usage guidance: "Use this to review what you're monitoring before adding more or to find an id to cancel." This tells the agent when to use this tool and implies when not to.

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

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

Even without meaningful annotations (all hints false), the description discloses key behavioral traits: filing without an account returns a claim_token, the token can be used later to read resolution status, rate limit is 5 per identifier per day, free and not quota-counted, and team reads digests daily. This goes well beyond the annotations.

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

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

Though long, every sentence delivers distinct information: purpose, when-to-use, when-not-to-use, content rules, token mechanism, team behavior, rate limit, and cost. It is front-loaded with the primary purpose and logically organized, with no filler.

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

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

The description fully covers the tool's purpose, usage boundaries, input guidance, post-filing behavior, and limitations. With no output schema, it explains the claim_token flow adequately. The nested context object is optional and described in the schema, so no gap remains.

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 explaining the claim_token parameter's round-trip usage ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and the fact that filing without an account yields a token. This extra context for the token parameter lifts it 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?

The description opens with a clear verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It explicitly enumerates the feedback categories (bug, feature/data_gap, praise) and distinguishes itself from sibling tools by limiting scope to tools served by this Pipeworx connection, which is a unique purpose.

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

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

The description gives explicit when-to-use conditions ('Use when a tool returns wrong/stale data...', 'when a tool you wish existed isn't in the catalog...') and a strong when-not-to-use exclusion for tools from other MCP servers. It also provides concrete guidance on what to include (Pipeworx tool names, not end-user prompts) and how to follow up with claim_token.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: data source (CF analytics-engine), privacy (no PII), output structure (pack, tool, count), and caching behavior (5min-1h depending on window). 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 efficient and well-structured: an opening sentence defining the output, followed by a bullet list of use cases, ending with technical details. Every sentence adds unique value without redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema, read-only), the description is fully complete. It covers purpose, output, usage contexts, technical behavior (caching, data source, privacy), and parameter semantics. 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?

The single 'window' parameter has 100% schema coverage with enum values. The description adds significant meaning beyond the schema by explaining that shorter windows surface current hotspots while longer windows show steady-state demand, aiding the agent in parameter selection.

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

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

The description clearly states the tool returns trending information ('top tools, top packs, total call volume') over recent windows. It uses specific verbs ('returns') and resources ('trending on Pipeworx'), and distinguishes from siblings like 'discover_tools' or 'ask_pipeworx' by focusing on aggregated call data from other AI agents.

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

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

The description provides three explicit use cases (discovering hot data sources, confirming canonical tool, aligning use case) which guide when to use the tool. However, it does not explicitly state when not to use it or name alternative tools from the sibling list, leaving some ambiguity for the agent.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds detailed behavioral context: monotonicity violation detection, partition checks, Jaccard similarity anchor, placeholders filter, fill check against CLOB depth. Explains when not to trade. No contradiction with annotations.

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

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

Description is relatively long but well-structured and front-loaded with main purpose. Every sentence provides value. Minor opportunity to combine some sentences for brevity, but overall concise given the complexity.

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

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

No output schema, but description thoroughly explains return structure: 'opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context)' and partition_check fields. Covers all modes, fill check, and references sibling tool for custom sizing. Complete for a complex arbitrage detection tool.

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

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

Schema has 100% coverage with descriptions for both parameters. Description adds significant meaning: explains each mode's semantics with examples (e.g., 'fed-decision-may-2026'), cross-event scanning behavior, and additional context like 'Full Polymarket URLs also accepted'. Goes well beyond schema.

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

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

Clearly states 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' Specifies verb+resource+method. Distinguishes three input modes (no args, event, topic), differentiating from sibling tools effectively.

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

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

Provides explicit when-to-use guidance for each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. Explains cross-event mode catches patterns single-event misses. Includes fill check advice and references polymarket_fill_risk for custom sizing.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds extensive behavioral details: caching (1h at KV level), model specifics (FRED log-returns, GDELT, partition overround with per-sport alpha), and that opportunities include edge_pp_net, kelly_fraction, etc. No contradictions with annotations.

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

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

The description is long but dense with information. It front-loads purpose, then details models, knobs, and response structure. Every sentence adds value, though some specifics (like exact alpha values for sports) are quite detailed. Well-structured given tool 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?

No output schema, but description details response top-level: by_segment, fed_candidates/fed_note, _diagnostics. It lists fields per opportunity (edge_pp_net, kelly_fraction, etc.) and explains caching and parameter effects. For a tool with 9 parameters and multiple models, the description covers all essential aspects for an agent to use it correctly.

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

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

Schema coverage is 100% (all 9 parameters described in schema), so baseline is 3. The description adds meaningful context beyond schema: e.g., min_kelly explains why filter is needed for small edges, slippage_pp mentions zero trading fees, min_partition_leg_kelly clarifies partition arbs have kelly_fraction_half=0 at parent level. This elevates the score.

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

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

The description clearly states it scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, specifically for 'what should I bet on today.' It enumerates three response segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT), distinguishing it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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 it's built for daily betting discovery without paging through many markets. Provides guidance on knobs like min_liquidity, max_spread_pp, and mentions Fed bets excluded from ranking. However, it lacks explicit when-not-to-use vs alternative tools, though sibling names provide some inference.

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 significant behavioral details: how data is generated (daily snapshots on cache-miss), what gaps mean, the 60-day TTL bound, and that decay uses daily closes. No contradiction with annotations.

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

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

The description is long but well-structured: core question, args, response fields, limits. Front-loaded with the main purpose. Each sentence adds value, though some repetition of schema details could be trimmed. Still, it's efficient for its depth.

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 thoroughly covers what the response contains (tracked, expired, snapshot_dates) and their fields. It also explains data gaps and history bounds. For a tool with two parameters and no output schema, this is complete.

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

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

Schema covers 100% of parameters with descriptions. The description rephrases 'days' as lookback and 'window' as family, but adds minimal new meaning beyond stating defaults and ranges. Given high schema coverage, baseline 3 is appropriate; the description does not extend understanding beyond the schema.

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

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

The description explicitly states the tool's purpose: tracking edge persistence and decay over time, distinguishing it from raw edge snapshots (polymarket_edges). It uses specific verbs ('track', 'answers') and resource ('edge persistence and decay telemetry'), clearly differentiating from sibling tools like polymarket_arbitrage or polymarket_fill_risk.

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

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

The description provides strong usage context by contrasting a fresh wide edge vs. an old one, implying when to use this tool for deeper analysis. It also explains the trade-off between window families and data availability, though it does not explicitly state when to avoid this tool or use 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, idempotentHint, destructiveHint=false. Description adds detailed behavioral traits: walks the ladder, returns specific metrics (top_of_book, vwap_fill_price, slippage, shares_filled, max_fillable_usd, verdict for single-market; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fills, thin_legs, max_clean_notional_usd, forced_directional_risk for basket). Warns about risks like partial fills converting arb to directional position.

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 well-structured with bold headings (SINGLE-MARKET, BASKET) and bullet points, front-loading key information. Every sentence adds value, covering modes, parameters, return values, and risks without unnecessary 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 fully explains return values for both modes. Also includes usage context, danger warnings, and ties to sibling tools. Covers all necessary aspects for an agent to decide and use correctly.

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

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

Schema coverage is 100% with descriptions, but the description adds deeper meaning: explains default behavior for side in basket mode (auto from partition sum), interprets size_usd differently for buys vs sells, and provides context for event and market parameters (slug vs URL).

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?

Describes specific resource (live CLOB order-book depth) and action (realizable-vs-theoretical edge check). Clearly distinguishes single-market and basket modes, and explicitly states it should be used before arbitrage actions or edges above $500, differentiating from sibling tools like polymarket_arbitrage.

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

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

Explicitly states when to use: before acting on polymarket_arbitrage SELL/BUY-EVERY-LEG signals or polymarket_edges trades above ~$500. Explains rationale: theoretical overround on thin books is not capturable, and partial basket fills create unhedged 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?

The description goes far beyond the readOnly/idempotent annotations by disclosing matching limitations, compatibility codes, unclassified-leg exclusion, gross vs. net spread treatment, and the standing fee caveat. It even explains that pairing_unverified applies in both modes and that null temporal alignment means 'could not be computed,' not confirmed alignment.

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

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

The description is long, but it is densely structured with clear labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS, Codes) and every section carries necessary caveats for a complex tool with no output schema. Some repetition exists around 'BOTH modes'/'EITHER mode', but the length is largely justified by the complexity.

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

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

With no output schema, the description must carry the burden of explaining return behavior, and it does: leg prices, top_spreads_pp flags, compatibility codes, temporal alignment, skipped counters, fees, and unclassified legs are all covered. An agent can understand what happens, what warnings to expect, and what is intentionally not modeled.

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

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

The schema already documents each parameter with descriptions and examples, so baseline is 3. The description adds meaningful behavior: the topic parameter auto-fetches matching events, and explicit ticker/slug parameters override the topic-mapped side. This clarifies how the three parameters interact beyond their individual schema entries.

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 first sentence states a specific resource and operation: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' The two modes and response structure further clarify what the tool computes, and the emphasis on matched spreads vs. unclassified legs distinguishes it from a simple price fetch.

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

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

The description clearly explains the two invocation modes (topic shortcuts vs. explicit ticker/slug pairings) and when each is appropriate. It also gives practical cautions like 'pre-mapped ≠ tradeable' and advises checking resolution dates when temporal_alignment_unknown. It does not explicitly name sibling alternatives, but the usage context is clear.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true. Description adds behavioral details: omitting key lists all keys, scoped to identifier, and pairing with siblings. 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?

Four sentences, each with distinct value: core function, usage context, scoping, and relationships. No redundant phrases.

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

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

For a simple tool with one optional parameter and full annotations, the description covers purpose, usage, scoping, and sibling relationships comprehensively.

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

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

Schema coverage is 100% and description adds critical meaning: omitting the key parameter lists all saved keys, which is not in the schema's description.

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

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

The description uses specific verbs 'retrieve' and 'list', identifies resource 'value previously saved via remember' and 'all saved keys', and distinguishes from sibling tools like 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 when to use: 'Use to look up context the agent stored earlier... without re-deriving it from scratch.' Mentions scoping and pairs with remember/forget, providing clear guidance on 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 indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral details: return fields (source, citation_uri, payload), mark_read flag updates read state so next call shows only newer events, and suggests polling is appropriate. 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, front-loaded with main action and key fields. Every sentence adds value: purpose, filter options, mark_read effect, polling and alternative access. No redundant or filler content.

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

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

No output schema exists, but the description lists return fields (source, citation_uri, payload) and explaines mark_read behavior. For a list/read tool with 5 optional parameters, the description covers key aspects. Slightly more detail on edge cases or default behavior could push it to 5, but it's sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reiterates 'type', 'since', and 'mark_read' but does not add significant new semantic meaning beyond what's in the schema. The explanation of 'mark_read' effect is useful but minor. 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 it pulls fired events from subscription feed and returns most recent alerts with specific fields. The verb 'pull' combined with 'fired events' and 'subscription feed' precisely defines the tool's action and resource, distinguishing it from sibling tools like 'subscribe' or 'list_subscriptions'.

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

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

Provides clear filter options (type, since) and explains mark_read behavior. Mentions polling is fine and gives an alternative access method (GET endpoint), offering good context for when to use this tool. However, it does not explicitly contrast with sibling tools for 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?

The description adds significant behavioral context beyond annotations: fans out to multiple data sources (SEC EDGAR, GDELT→GNews, USPTO), explains fallback logic, and mentions the PatentsView sunset soft-failure. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint=false).

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

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

The description is dense and front-loaded with example queries, covering all aspects in a single paragraph. Every sentence is informative, though it could be slightly restructured for easier scanning.

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

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

Despite no output schema, the description explains the return structure: 'structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs'. It also addresses edge cases like the USPTO soft-failure. This is complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds value: explains 'since' accepts ISO or relative formats, gives examples ('7d', '30d', '1y'), suggests '30d' for monitoring. For 'value', specifies ticker or zero-padded CIK. For 'type', states only 'company' is supported.

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

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

The description clearly states the tool provides a change feed for a company (SEC filings, news, patents) within a time window, and distinguishes it from the sibling 'entity_profile' tool which provides static profiles. It is specific about the verb ('change feed') and the resource (company recent changes).

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

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

Explicitly tells when to use this tool vs alternatives: 'Use entity_profile instead when you want the static profile ...'. Also provides example queries and suggests typical monitoring parameters like '30d'.

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 persistence behavior beyond annotations: authenticated users get persistent memory, anonymous sessions retain for 24 hours. 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?

Concise, front-loaded with core action, then usage context, then details. Every sentence is useful.

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

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

Covers scope, persistence, and relationship to sibling tools. No output schema needed for this simple write tool.

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

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

Schema covers both parameters with descriptions. The description adds that it's a key-value pair but doesn't significantly enhance schema information.

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

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

Clearly states the verb 'Save data' and the resource 'data the agent will need to reuse later'. Distinguishes itself from sibling tools 'recall' and 'forget', and specifies key-value scoping.

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

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

Provides explicit guidance on when to use: 'when you discover something worth carrying forward'. Mentions pairing with recall and forget, but does not explicitly state when not to use.

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

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

With readOnlyHint, openWorldHint, and idempotentHint already present, the description adds meaningful behavioral context: results may include multiple candidates (figi_candidates), unresolvable identifiers are surfaced under 'unresolved' rather than omitted, and LEI/FIGI enrichment degrades gracefully when upstream sources are unavailable. It also notes internal cascading lookups. This exceeds what annotations alone convey.

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

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

The description is overloaded as one dense run-on paragraph with interleaved examples, nested parentheticals, and abrupt topic shifts. While most content is useful, the lack of clear sections or sentence-level structure makes it hard to scan. It is more sprawling than concise, despite the front-loaded 'Use FIRST' 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?

There is no output schema, so the description carries the burden of explaining return values. It covers the identifier families returned, candidate and unresolved behavior, graceful degradation, and the internal cascade that replaces multiple manual lookups. It is not exhaustive about the exact response shape, but it is complete enough for an agent to call the tool and interpret results.

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

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

Although schema coverage is 100%, the description adds substantial practical meaning beyond the schema: accepted input formats per type, explicit warning to pass only the entity name and never the full question noun phrase, bond issuer formatting guidance, and ISIN example semantics. This materially helps an agent populate the value parameter correctly.

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

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

The description clearly states the tool resolves user-spoken names to canonical identifiers, enumerates supported entity types ('company', 'drug'), and names the identifier families (CIK, LEI, FIGI, RxCUI). It is specific about the verb and resource, though it does not explicitly differentiate itself from sibling tools like entity_profile or compare_entities beyond the generic 'Use FIRST' guidance.

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

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

The description gives explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also clarifies scope, such as resolving bonds via issuer names and covering non-US issuers through ISIN-to-LEI. However, it does not state when NOT to use the tool or name an alternative tool for situations where an ID is already available.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description reveals it probes each entity with 'ai_visibility_check', ranks results, and returns score, confidence, signal density. 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?

Three sentences: purpose, explanation with example, output summary. No unnecessary words; each sentence adds unique value.

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

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

Covers input, behavior, output, and use case. Lacks explicit mention of entity count limits (2-8, but present in schema) and potential error handling. Overall, sufficient for agent decision-making.

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 explaining that the first entity is the 'subject', that models can be omitted, and that context disambiguates names.

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 compares AI visibility across multiple entities, ranks them, and surfaces the most/least recognized. It distinguishes from siblings like 'ai_visibility_check' (single entity) and 'compare_entities' (generic).

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

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

It provides a concrete use case ('competitive AI-marketing audits') and an example question. It implicitly differentiates from single-entity tools but does not explicitly 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context about partial failures, bundlephobia timing, and the sources_failed field, 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 long but front-loaded with the key purpose. It includes necessary detail without being verbose; every sentence adds value. Could be slightly more concise.

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

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

With no output schema, the description fully explains the return structure (summary block, advisories, links, alternative versions) and addresses limitations (bundlephobia timing, graceful degradation). Complete for the tool's complexity.

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

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

Schema coverage is 100% so the schema itself documents parameters. The description adds minor context (scoped packages accepted, version defaults) but does not significantly expand 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 is a composite check for npm packages covering license, advisories, version history, and bundle size. It distinguishes from other ecosystems by noting PyPI/Maven etc. are handled elsewhere.

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 an agent asks about safety, popularity, or size of an npm package. Also provides exclusion guidance for other package ecosystems.

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, openWorldHint, and destructiveHint false. The description adds valuable details: character offsets, similarity scores, embedding model (BGE-base-en), window size (500-char overlapping), and character limit (200K with truncation flag).

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, front-loaded sentences. Every part adds value: purpose, use case, technical details, and pairing advice. 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 3 parameters and no output schema, the description covers behavior well (window size, truncation, offsets, similarity scores). Only missing explicit mention of return format but implied by 'passages with character offsets and similarity scores'.

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

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

Schema coverage is 100% so baseline is 3. The description adds value with examples for the 'query' parameter and explains the default for 'limit'. It doesn't repeat schema but enhances 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 'Semantic search INSIDE a fetched record' with specific examples like SEC 10-K and articles. It distinguishes from sibling tools by explaining the use case (too big for prompt) and pairing with ask_pipeworx_grounded.

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

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

Explicitly states when to use: 'Use when the record is too big to cram into the prompt.' Also mentions pairing with ask_pipeworx_grounded for grounding, implying an alternative workflow.

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

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

The description goes beyond annotations, disclosing details like return value, account requirements, per-type parameter usage, delivery channel specifics (e.g., phone verification, 10/day cap, webhook secret, auto-disable after failures). No contradictions with annotations.

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

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

The description is long but well-structured, front-loading the main purpose. Every sentence adds value, though some redundancy exists (e.g., 'persist subscriptions' and 'always-on persistent feed'). 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?

The description covers the return value, constraints, and usage examples for all types and delivery channels. It does not explicitly address error handling but is sufficient given no output schema. Could mention idempotency behavior, but not critical.

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

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

Input schema coverage is 100%, but the description adds significant meaning: it explains each type's param structure with examples and delivery options with constraints. This enriches the schema and helps correct invocation.

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 creates a proactive monitoring subscription to a live-data event stream and returns the subscription ID. It distinguishes itself from siblings like list_subscriptions and unsubscribe by focusing on creation and proactive monitoring.

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 (to set up ongoing monitoring) and mentions requirements (Pipeworx OAuth account, verified phone for SMS). It doesn't explicitly list when not to use or alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond these: it returns category-bucketed examples and draws from a live catalog. It does not discuss return format or size limits, but for this kind of discovery tool, the provided information is adequate.

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 common questions to establish context, then explaining the return format and usage. Every sentence serves a purpose. Could be slightly shorter, but remains effective.

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

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

Given the simplicity of the tool (1 optional param, no output schema) and the presence of informative annotations, the description is complete. It explains what the tool does, when to use it, how to customize it, and the type of output expected. No additional information is 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% for the single optional parameter. The description adds meaning by listing possible values (finance, pharma, etc.) and their effect ('focus'), and explicitly states that omitting the parameter gives a cross-category spread. This goes beyond the schema's basic description.

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

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

The description clearly identifies the tool as the onboarding entry point for a Pipeworx agent. It uses specific verbs ('returns category-bucketed example questions') and resources ('the onboarding entry point'), and distinguishes itself from siblings like ask_pipeworx or entity_profile by stating its role in learning what Pipeworx can do.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. It also explains the two invocation modes (no arguments for full spread, or with topic for focus). It lacks an explicit 'when not to use', 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?

Annotations indicate non-destructive and idempotent; description adds ownership check and deactivation behavior, providing further 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?

Three concise sentences, front-loaded with purpose, no extraneous information.

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

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

For a simple 1-param tool with no output schema, description fully specifies usage, ownership, and outcome, linking to related 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 100% with clear 'id' description. Description adds no further 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?

Clear verb-resource pair: 'Cancel a subscription by id'. Distinct from siblings like 'subscribe' and 'list_subscriptions'.

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

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

States ownership enforcement and effect (deactivation vs deletion). Provides explicit context for when to use and what happens.

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

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

Annotations already mark the tool as read-only, open-world, and idempotent. Beyond that, the description reveals two execution pipelines, the full verdict set, and the critical behavioral distinction between could_not_verify (check failed) and unsupported (no source found). It also notes it replaces multiple sequential calls, adding behavioral context beyond what annotations provide. 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 but justifiably so. It packs examples, two paths, verdict meanings, a caveat, and the value proposition into one paragraph. It is well-structured and front-loaded with examples, though slightly verbose for a tool description. Every sentence earns its place given the complexity.

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

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

There is no output schema, so the description must explain return values, and it does: the verdict list, actual value with citation, and reasoning. It also covers edge cases (could_not_verify vs unsupported), mentions the authoritative sources (SEC EDGAR, grounded live sources), and explains the automation benefit. For a tool with this many moving parts, the description is complete.

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

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

The input schema provides thorough descriptions for both parameters (100% coverage), so the baseline is 3. However, the description enriches understanding by mentioning 'exact percent-delta math' and the role of tolerance in verdicts, which helps the agent understand how tolerance_pct influences grading. It adds meaningful context about the underlying computation without repeating schema details.

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

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

The description begins with concrete natural-language examples and explicitly states the tool's function: 'natural-language claim verification against authoritative sources.' It clearly distinguishes itself from sibling tools like ask_pipeworx by focusing on fact-checking with a verdict, and it explains the two routing paths (company-financial vs. other claims), making the purpose unmistakable.

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

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

The description provides direct guidance with 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing logic and gives an important caveat about could_not_verify not being used as evidence, showing when and how to interpret results. It does not explicitly name alternative tools or state when not to use it, but the scope is clear enough.

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