Passwordgen

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool makes external API calls (Anthropic with BYO key) and returns per-model details plus combined view. No contradictions with annotations.

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

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

Three sentences with no fluff. Core action stated first, then optional details and use cases. Every sentence adds value.

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

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

For a tool with 4 well-documented parameters and no output schema, the description covers input details, return structure (per-model scores, confidence, signals, raw_response, combined view), and use cases. 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 description coverage is 100%, so baseline is 3. The description adds value by explaining the default model and the role of _apiKey, providing context for the 'context' parameter (disambiguation example), and summarizing return fields.

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

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

The description uses a specific verb ('probe') and resource ('LLMs') and clearly states the output (score visibility 0-100 per model). It differentiates from sibling tools like ask_pipeworx (general Q&A) and scan_competitor_ai_presence by focusing on multi-model visibility scoring.

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

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

The description explicitly states default model, how to use Anthropic with a key, and lists use cases (AI-marketing audits, pre-launch checks, competitive monitoring). However, it does not explicitly mention when not to use this tool or name alternative sibling tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict these. The description adds useful behavioral context by explaining that the tool routes to a large tool ecosystem, fills arguments automatically, and returns stable citation URIs. This goes beyond bare 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 repeats the same 'START HERE for most questions...' block and example list multiple times, creating significant redundancy. The opening sentences are front-loaded and high-value, but the repetitive tail wastes tokens and makes the description harder to parse. A more disciplined single pass would earn a higher score.

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

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

For a single-required-parameter tool with strong annotations, the description is largely complete: it covers domains, trigger phrases, examples, routing behavior, and the nature of the output (structured answer with citation URIs). It does not address edge cases like 'no matching tool', but that is a minor gap given the wealth of context already provided.

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

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

Schema description coverage is 100%; all six parameters are documented as aliases for a natural-language 'question'. The description reinforces this with example queries and says the tool 'fills arguments', but it does not add substantive meaning beyond the schema's own parameter descriptions. The baseline of 3 applies.

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

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

The description clearly states the tool's purpose: it routes factual questions about real-world data to one of 5,798 tools and returns structured answers with pipeworx:// citation URIs. It names concrete domains (SEC filings, FDA, FRED/BLS, USPTO, etc.), which makes the function vivid. However, it does not differentiate itself from closely-named siblings such as ask_pipeworx_grounded or ask_pipeworx_beta, so it stops short of a 5.

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 trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), a list of data categories, and instructs agents to 'START HERE for most questions' and 'PREFER OVER WEB SEARCH'. This is strong guidance for when to use the tool. It does not, however, mention when to prefer sibling tools like deep_research or validate_claim, so it is not fully discriminating.

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

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

Annotations already declare readOnly and idempotent behavior, and the description adds meaningful context beyond them: it is a live experimental build, candidates are enabled only when under test, currently nothing is active, and it is a full working router rather than a fallback stub. This gives the agent a clear operational picture 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 dense but efficient: it front-loads the tool's identity and relationship to ask_pipeworx, then explains the current candidate state. The 'Falls back to nothing' phrasing is slightly counterintuitive, but the follow-up clarification keeps it from being misleading.

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

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

For a simple single-question tool, the description provides current operational status, the relationship to the stable router, and response-shape identity. It omits concrete examples or an explicit note about what kinds of questions are appropriate, but the universal-router framing and schema cover most needs.

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

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

Schema description coverage is 100% and the input schema already documents `question` and all its aliases. The description only says 'same arguments' and adds no additional parameter-level meaning, which matches the baseline for high schema coverage.

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

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

The description is specific: it identifies a beta version of ask_pipeworx, a universal router with the same 5,798 tools, same arguments, and same response shape. It clearly differentiates from the stable ask_pipeworx sibling by describing the experimental candidate-routing 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?

It states when to use the tool: when the newest experimental routing is desired, and notes it should be used exactly like ask_pipeworx. It explains that no candidate is currently active, so behavior currently matches ask_pipeworx. It does not explicitly say when NOT to use it versus ask_pipeworx or ask_pipeworx_grounded, but the context is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds substantial behavioral context: extraction uses only tool result content, success returns evidence with verbatim quotes, and failures produce explicit refusal reasons. It also discloses the extra LLM call cost, which is not visible in annotations.

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

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

The description is dense but well-structured: purpose, behavior, return format, refusal modes, usage conditions, and trade-off guidance are all packed into a compact block. Every clause earns its place, and critical scoping is front-loaded in the first sentence.

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

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

Despite having no output schema, the description fully explains the return contract, including the success shape and all refusal_reason enum values. It also covers when to use and when not to use the tool, making the description complete for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, with all six parameter properties documented as aliases for 'question.' The description adds no parameter-specific meaning beyond what the schema already provides, so the 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 opens with a specific verb and resource: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly distinguishes itself from the sibling ask_pipeworx by contrasting the grounded extraction behavior with the standard routing flow, so an agent understands exactly what makes this tool different.

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

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

Explicit guidance is given: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and 'prefer ask_pipeworx for casual lookups.' It names the alternative tool and the cost trade-off, leaving no ambiguity about when to select this tool versus its sibling.

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, idempotent=true, destructiveHint=false, but the description adds extensive behavioral detail: resolution process, fan-out logic, response shapes, resolver contract, parent extractor, news fields, safety/edge cases, wide-spread handling, and resolution-rule risk. No contradictions with annotations.

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

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

The description is well-organized with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, etc.) but is quite verbose at ~600 words. While every sentence adds value, the length impacts conciseness. More succinct phrasing could improve readability.

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

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

Given the tool's complexity (3 parameters, no output schema) and broad scope, the description is remarkably complete. It covers input resolution, classifier types, fan-out patterns, response structure, confidence handling, edge cases (closed markets, wide spreads, resolution rules), and safety checks. No significant gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description provides examples and context for the market parameter (slug/URL/question) and explains depth's quick/thorough modes, but these are already covered in the schema descriptions. No new parameter-level constraints or format details beyond schema.

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

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

The description clearly states 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call' with specific verb and resource. It distinguishes from sibling tools like polymarket_arbitrage by focusing on individual bet research. Examples of input types (slug, URL, question) further clarify scope.

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

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

Explicit usage guidance is given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This clearly indicates when to use the tool. However, it does not explicitly state when not to use it or mention alternatives by name, so it misses some exclusion context.

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

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

Despite annotations already marking it as read-only and idempotent, the description adds rich detail: it pulls financial data from SEC EDGAR/XBRL, handles off-calendar fiscal years, for drugs pulls FAERS data, and returns sorted results with citation URIs.

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

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

The description is relatively long but every sentence adds value. It is front-loaded with example queries and structured to first state purpose, then usage context, then behavior. Could be slightly more concise but well-organized.

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

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

Given no output schema, the description compensates by explaining the return format (paired data + citation URIs). It covers both entity types, data sources, edge cases, and replaces 8-15 sequential lookups. 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%, baseline 3. The description adds user-facing examples and clarifies that for company, values are tickers/CIKs; for drug, drug names. This adds meaningful context beyond the schema descriptions.

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

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

The description clearly states it does side-by-side comparison of 2-5 companies or drugs, with example queries like 'compare X and Y' or 'which is bigger'. It distinguishes from sequential single-entity lookups and sibling tools like entity_profile.

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

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

It explicitly states 'ALWAYS PREFER over sequential single-pack lookups' and provides user query examples. It doesn't explicitly state when not to use, but the context is clear that it's for comparative queries.

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 account requirements, latency (15-60s, up to ~90s for thorough), return-packet contents (verbatim evidence, confidence, source, fetched_at, citation_uri), the explicit gaps[] contract ('never invented'), contradictions[] behavior, and semantic excerpting of large records. This is rich, non-obvious behavioral context.

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

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

The description is long but every section adds necessary context for a complex tool with no output schema: auth, alternatives, core mechanism, return fields, depth behavior, citation guarantees, and latency. It is front-loaded with the account requirement and alternative routing, though the prose is denser than needed in the middle.

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 high-complexity tool with no output schema, the description is exceptionally complete: it explains what the tool returns, how findings are sourced, what gaps and contradictions mean, how citations are guaranteed fetchable, which depth to choose, what to expect on latency, and when to use a sibling instead. An agent has enough to invoke and interpret results 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?

Input schema coverage is 100%, so the baseline is 3; the description adds value beyond the schema by tying depth levels to paid plans, latency expectations, gap recovery, and contradiction detection. It also provides concrete example questions, reinforcing that 'question' accepts broad, multi-part natural language.

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

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

The description states a specific verb ('research') and resource ('Pipeworx's 1517 STRUCTURED data sources'), and clearly differentiates from siblings by saying 'this is NOT open-web search' and contrasting with ask_pipeworx for single lookups. It also indicates this is for broad/multi-part questions, which is a sharper scope than a generic research tool.

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 routing guidance: use ask_pipeworx if not signed in or for a single lookup, and use deep_research for broad/multi-part structured-data questions. It also notes the paid requirement for depth:'thorough', telling the agent when a specific parameter value is unavailable.

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 (readOnly, idempotent, non-destructive), the description adds key behavioral details: returns top-N most relevant tools with names, descriptions, full input schemas with curated examples, and is ready to call directly without second lookup. No contradictions with annotations.

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

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

The description is well-structured with front-loaded purpose, examples, return value, and usage guidance. It is informative but slightly verbose with multiple examples; could be tightened slightly without losing clarity.

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

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

For a discovery tool with no output schema, the description fully explains what the tool returns (relevant tools with schemas/examples) and when to use it. All necessary context is provided given the tool's simplicity.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description provides example queries but does not add significant meaning beyond what the schema already offers. 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 explicitly states 'Find tools by describing the data or task' and lists numerous example domains (SEC filings, financials, etc.), clearly distinguishing this discovery tool from siblings like 'deep_research' or 'ai_visibility_check' that have different purposes.

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

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

The description provides explicit guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This tells the agent when to use and implies when not to (if seeking a single answer, use other tools directly).

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 far beyond the readOnly/openWorld/idempotent annotations: the parallel fan-out across nine named sources, the specific return fields (recent_filings up to 5 with pipeworx URIs, LATEST 10-K fundamentals), and failure semantics ('sources_failed', 'an empty section is a real no data, not a bug'). It also preempts confusion on expected absences — a small-molecule-only drug company showing no fda_products 'is expected, not a failure' — and describes the private-company resolved:false case. All of this is consistent with the annotations.

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

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

The description is information-dense and every clause carries real content, but it is a roughly 280-word single block with deep parenthetical chains that are difficult to scan. It also contains a visible garbled artifact in the fundamentals section ('Cash, sorted Cash, sorted...') that undermines trust in the return-value enumeration. Front-loading of example queries and the ALWAYS PREFER directive is good, but the wall-of-text structure and the corruption prevent a higher score.

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

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

With no output schema present, the description carries the full burden of documenting the return shape, and it does so exhaustively: every section (cik, company_name, resolved_from/to, recent_filings with URI format, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI) is named with its source and semantics. Input variants, resolution behavior, expected absences, and sources_used/sources_failed semantics are all covered. The only notable gap is the garbled fundamentals detail.

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

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

Schema coverage is 100% and the schema already provides examples, the SEC EDGAR resolution note, and the type-interchangeability statement, setting a baseline of 3. The description adds value beyond the schema by specifying private-company behavior (resolved:false plus an explicit notes line), emphasizing zero-padding for CIKs, and confirming that type accepts 'company' or 'ticker' interchangeably for all value shapes.

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 the exact task — "full cross-source profile of a US public company in ONE parallel call" — backed by a rich set of natural-language triggers ('tell me about X', 'research Acme', 'brief me on Tesla', 'company profile for Microsoft'). The scope is precise (US public companies only, single entity) and the explicit 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' directive carves out its niche against siblings like deep_research, compare_entities, and resolve_entity.

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

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

It gives an explicit trigger and preference rule: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' plus a clear out-of-scope behavior for private companies (resolved:false with a notes line). However, it does not route adjacent intents to any sibling — e.g., deep_research for deeper dives or compare_entities for cross-company comparisons — so exclusions are partial rather than complete.

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

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

Annotations already indicate destructive and idempotent behavior. The description adds context about sensitive data clearing, but doesn't specify behavior for missing keys or confirm idempotency explicitly.

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: first states purpose, second provides usage guidance and sibling pairing.

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 simple single-parameter tool, the description fully covers purpose, usage, and pairing with siblings, leaving no gaps.

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

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

Schema coverage is 100% and the description repeats the parameter name without adding new detail; baseline score 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 action ('Delete a previously stored memory by key') and distinguishes from sibling tools by positioning itself as the deletion counterpart to 'remember' and 'recall'.

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

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

Explicitly lists when to use (stale context, task done, clear sensitive data) and indirectly when not (use remember/recall instead), providing clear decision guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, indicating safe, idempotent operation. The description adds process details (fetches page, extracts title/description/links, emits markdown) and output format, providing transparency 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 concise (3 sentences) and front-loaded with the main purpose. It includes practical examples and use cases without unnecessary verbosity.

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

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

Given no output schema, the description explains the output format (single text blob) and process. However, it lacks details on error handling, edge cases, or exact markdown structure. For a simple tool with 2 parameters, it is adequate but not fully 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 descriptions fully cover both parameters (url, max_links). Description does not add additional parameter-level context beyond schema. With 100% schema coverage, 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 the tool's purpose: generate a production-ready llms.txt file for any URL. It specifies the verb (generate), resource (llms.txt file), and context (for AI crawlers). This distinguishes it from siblings by focusing on a specific output format and use case.

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

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

The description provides explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor. It does not mention when not to use or alternatives, but the use cases are concrete and helpful for decision-making.

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

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

The description adds significant behavioral context beyond annotations: 'keyless, offline, CSPRNG' and that it returns entropy in bits. Annotations already indicate read-only, open-world, idempotent, and non-destructive.

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 are highly efficient, front-loading the core purpose and key features without any redundant or irrelevant 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?

The description is adequate given the comprehensive schema and annotations. It mentions return values (passwords and entropy) despite no output schema. Could explicitly mention that 'count' generates multiple passwords, but the examples in the schema compensate.

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

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

Schema coverage is 100%, so the schema already documents all 7 parameters. The description adds a high-level summary ('Control the character sets and length') but does not provide detailed meaning beyond what the schema offers.

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

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

The description clearly states the verb ('Generate'), the resource ('cryptographically-random password(s)'), and key attributes ('keyless, offline, CSPRNG'). It distinguishes from the sibling 'generate_pin' by specifying CSPRNG and entropy return.

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

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

The description implies usage for password generation but does not explicitly state when to use this tool vs alternatives (e.g., 'generate_pin' for numeric pins). No when-not guidance is provided.

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

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

Adds context beyond annotations: 'cryptographically-random' explains non-deterministic output, 'keyless, offline' clarifies environment. However, annotation idempotentHint=true contradicts randomness, implying potential confusion.

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

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

Single short sentence with zero wasted words. Includes essential purpose and key qualifiers (cryptographically-random, keyless, offline).

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, so description should hint at return format. It does not specify whether output is a single string or array for multiple PINs, though the count parameter implies multiple.

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 provides full coverage (100%) with descriptions for both parameters (count, length) including defaults and ranges. Description adds no additional parameter 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?

Clear verb ('Generate') and specific resource ('cryptographically-random numeric PIN'). Qualifiers 'keyless, offline' distinguish it from sibling tools like 'generate_password'.

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

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

No explicit when-to-use or when-not-to-use guidance. Implicitly suggests offline keyless use case, but does not mention alternatives or constraints relative to 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, idempotentHint=true, destructiveHint=false. The description adds value by listing the return fields and usage context. No contradiction.

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

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

Two concise sentences that cover purpose, return values, and usage. No wasted words.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is fully adequate: it explains what is returned and why to use it.

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

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

Schema coverage is 100% with a single parameter described in the schema. The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states 'List the caller's active subscriptions' and specifies the returned fields (id, type, params, etc.). It distinguishes itself from sibling tools like 'subscribe' and 'unsubscribe'.

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

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

The description provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' It doesn't explicitly state when not to use it, but the context is clear given sibling tools.

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

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

Discloses rate limit (5 per identifier per day), that it's free, doesn't count against tool-call quota, returns a claim_token for later retrieval, and that the team reads digests daily. This goes well beyond annotations which only have false hints.

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

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

The description is comprehensive but somewhat dense as a single paragraph; every sentence is relevant, but it could benefit from better structural formatting. It is front-loaded with the core purpose.

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

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

With no output schema and all optional parameters, the description covers the claim_token flow, rate limits, exclusions, message guidance, and even the type-specific use cases. It's fully contextual for a feedback 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, but description adds important semantics: how to use claim_token for follow-up (pass with no other arguments), and guidance on message content (describe in terms of Pipeworx tools/packs, don't paste end-user's prompt). This enriches parameter understanding.

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

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

The description clearly states the tool sends feedback to the Pipeworx team about broken, missing, or needed functionality. It distinguishes from sibling tools like ask_pipeworx or discover_tools by specifying it's for reporting issues/praise about this specific MCP connection.

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 (bug, feature/data_gap, praise) and explicitly says NOT to use for other MCP servers, directing to file with that server instead. Also gives 'Not sure?' guidance for identifying Pipeworx 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?

Adds info about data source (CF analytics-engine), no PII, and caching duration. Annotations already declare readOnly, idempotent, etc., and description complements without contradiction.

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

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

Two sentences plus bullet points, front-loaded with purpose, no extraneous text. Every sentence adds value.

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

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

Given low complexity (1 param, no output schema), description covers purpose, usage, behavioral details, and param semantics completely. Agent can confidently use the tool.

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

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

Parameter window has 100% schema coverage with enum values. Description adds meaningful guidance on how window length affects results (hot now vs steady-state).

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

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

Clearly states it returns top tools, packs, and call volume over configurable windows, with specific use cases. Distinguishes from siblings like ask_pipeworx or discover_tools by focusing on trending aggregate data.

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 three use cases and explains window semantics. Does not explicitly mention when not to use, but context is sufficient for correct selection.

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

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

Annotations already declare the tool as read-only (readOnlyHint), non-destructive, and idempotent. The description adds extensive behavioral context: the logic of monotonicity checks, partition sum verification, semantic anchor (0.30 Jaccard similarity), placeholder filtering, and fill check against live CLOB depth. It explains the output structure and when a signal is not actionable, far exceeding what annotations provide.

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

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

The description is long but well-structured with clear sections (modes, semantic anchor, partition filter, fill check). Every sentence adds value for a complex tool, though some details (like specific Jaccard threshold) could potentially be simplified. It is front-loaded with the core 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?

Despite no output schema, the description fully explains the return format: opportunities[] with fields (gap_pp, suggested_trade, reasoning, monotonicity violation context) and in event mode a partition_check object. It covers edge cases like low similarity, placeholder filtering, and book depth validation, making the tool's behavior self-contained.

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

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

Schema coverage is 100% with both parameters documented. The description adds significant meaning beyond the schema: it explains that event accepts full Polymarket URLs, describes the behavior of the topic parameter (search related events, flatten markets, run comparator), and details the semantic anchor and partition filter thresholds.

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

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

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

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

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

The description explicitly states when to use each argument: 'Call with NO args for a trending_scan...', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. It provides guidance on when not to trade (realizable_edge_pp ≤ 0) and references polymarket_fill_risk for custom sizing, which implies an alternative.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds extensive behavioral detail: caching 1h at KV level, segment-by-segment model families, edge calculations, diagnostics for empty segments, and knob effects. 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 very long and detailed, with extensive model family explanations. While the first sentence front-loads the purpose, the length may overwhelm an agent. It could be more concise by moving model details to a separate section or documentation.

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

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

Given the tool's complexity (9 parameters, no output schema, multiple segments), the description is comprehensive. It covers response structure, edge calculation, knobs, caching, and diagnostics, leaving no major gaps for an agent to use the tool correctly.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds extra context beyond the schema, such as explaining the purpose of min_partition_leg_kelly and how category_filter combines segments. This adds value without repeating 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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, targeting 'what should I bet on today'. It distinguishes from siblings like polymarket_arbitrage and polymarket_edge_tracker by focusing on edge detection rather than fill risk or cross-market spreads.

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

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

The description provides clear context: it's for discovering betting opportunities and mentions that Fed bets are excluded from ranking with an explanation. While it doesn't explicitly state when not to use, the example usage and segment breakdown offer good 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?

The description adds significant behavioral detail beyond the annotations, including that data comes from daily snapshots with possible gaps (cache-miss days), a 60-day snapshot TTL, decay computed from daily closes (not intraday), and a full explanation of the response structure (tracked, expired, snapshot_dates). This exceeds the safety profile provided by 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 somewhat verbose but well-structured, starting with the core purpose and then detailing args, response, and limits. Each sentence adds value, but it could be trimmed slightly without losing clarity.

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

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

Given no output schema, the description thoroughly explains the response format including tracked[], expired[], and snapshot_dates[] arrays, along with data limitations. It covers missing data, TTL, and computation methods, making it complete for an agent to 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?

The input schema already has 100% coverage with descriptions for both parameters. The description adds default values and ranges (days default 14, clamp 2-30; window default '1wk' with family options), which is useful but does not significantly increase understanding beyond the schema.

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

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

The description clearly states that the tool tracks edge persistence and decay from daily snapshots, answering the specific question of how long an edge has existed and whether it is shrinking. It distinguishes from the sibling 'polymarket_edges' tool by focusing on historical telemetry rather than current edge data.

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 a clear usage context: to differentiate between fresh and old edges for trading decisions. It implies when to use this tool (when edge age matters) but does not explicitly state when not to use it or name specific alternatives, though sibling tool names offer context.

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

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

Annotations already mark as read-only, idempotent, non-destructive. Description adds behavioral context: it walks the order book, returns fill details (verdict, slippage, etc.), and warns about risks (partial fills convert arb into directional position). No contradiction.

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

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

Well-structured with bolded mode sections and front-loaded purpose. Slightly verbose (~200 words) but every sentence adds value given the tool's complexity. Could be trimmed slightly.

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, so description fully explains return values for both modes (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict; for basket: theoretical_sum, realizable_sum, capture_ratio, profit_usd, thin_legs, etc.). Addresses all required context for safe use.

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

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

Schema coverage is 100%, but description adds meaning beyond schema: explains when to use market vs event, side defaults and auto-detection, and differing interpretations of size_usd between modes. Provides necessary context for correct parameter 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?

Clearly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth', distinguishes between single-market and basket modes, and differentiates from siblings by specifying when to use (e.g., before acting on polymarket_arbitrage signals).

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 THIS before acting on any polymarket_arbitrage...or any polymarket_edges trade above ~$500'), why (theoretical overround not capturable, partial fills create unhedged positions), and prerequisites (one of market or event).

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 and idempotentHint already present, the description goes well beyond them by disclosing that spreads are gross of Kalshi fees, that null temporal_alignment does not mean aligned, that unknown legs are never paired, and that pairing_unverified is always set when pairs are returned. These are genuine behavioral disclosures an agent needs.

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 deliberately structured with labeled sections (modes, response, safety fields, fees, counters). It front-loads the core purpose and then details edge cases. It is slightly repetitive around pairing_unverified and the identical matcher claim, so it could be tightened, but the density is largely justified by the tool's complexity.

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

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

There is no output schema, so the description carries the full burden of explaining the response. It documents leg prices, top_spreads_pp, compatibility_codes, per-pair flags, temporal_alignment semantics, fees_note, skipped counters, and suitability caveats. An agent has enough context to invoke either mode and interpret results correctly.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that topic is a mode shortcut, that kalshi_event_ticker and polymarket_event_slug override the mapped side, and that all three parameters are optional but lead to different pairing behavior. The examples in the schema are reinforced by the description's mode explanation.

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 resource and verb: cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes the two operating modes and the custom pairing path, giving an agent a clear picture of what the tool does without opening the schema.

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

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

It gives strong usage context: two modes, how to choose explicit tickers, and guidance to read compatibility fields and to manually verify temporal alignment when unknown. It stops short of explicitly contrasting this tool with siblings like polymarket_arbitrage or polymarket_edges, so the guidance is clear but not alternative-aware.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds scoping detail (anonymous IP, BYO key hash, account ID) and the dual behavior of omitting key to list all, exceeding 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?

Three sentences, front-loaded with the core action, no wasted words, 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?

Covers dual behavior, scoping, and relationships to siblings. Lacks return format details but adequate given low complexity.

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

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

Schema coverage is 100% but description adds clarification that omitting key lists all saved keys, providing context beyond the schema's property description.

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

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

The description clearly states the tool retrieves a value or lists keys, naming the resource ('value previously saved via remember') and distinguishing from sibling tools '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 tells when to use ('look up context the agent stored earlier') and pairs with related tools, 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?

The annotation declares readOnlyHint: true, implying no state changes, yet the description explicitly describes mark_read:true as a state-modifying operation. This is a direct contradiction, resulting in a score of 1.

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 and covers all key aspects without unnecessary verbosity. It is well-structured and front-loaded with the primary action, though it 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?

Given the absence of an output schema, the description adequately explains return values (source, citation_uri, raw payload) and side effects. It also covers filtering and alternative access, making it fairly complete.

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

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

The schema coverage is 100%, and the description adds meaningful context for each parameter, especially mark_read and unread_only, explaining their behavioral impact beyond the schema descriptions.

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

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

The description clearly states 'Pull fired events from your subscription feed,' specifying the action (pull) and resource (alerts). It distinguishes itself from sibling tools by focusing on recent alerts from the feed.

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

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

The description provides clear usage context, including filtering options (type, since) and polling suitability. It also mentions an alternative access method via GET endpoint. However, it does not explicitly state when not to use this tool or compare 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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details: it fans out to multiple APIs with fallback logic (GDELT preferred, GNews on rate limit or 5xx), notes USPTO's PatentsView API sunset risk, and explains the return structure (changes[] grouped by source with citation URIs).

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

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

The description is dense but well-structured, starting with example queries and then detailing sources and parameters. Every sentence adds useful information with no filler. Could be slightly more structured with bullet points, but it is efficient and clear.

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

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

Given the tool's complexity (multiple sources, fallback logic, parameter formats) and the absence of an output schema, the description fully covers: when to use, what it does, parameter details, output structure (changes[] grouped by source + total_changes + citation URIs), and known limitations (USPTO soft-fail). Nothing essential is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the `since` parameter format with examples ('2026-04-01', '7d', '30d', '3m', '1y') and recommending '30d' or '1m' for typical monitoring. It also clarifies `value` accepts ticker or CIK.

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

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

The description clearly states the tool's purpose as a 'change feed for a company in the last N days/weeks/months' and lists the sources (SEC EDGAR, GDELT→GNews fallback, USPTO). It explicitly distinguishes from the sibling tool 'entity_profile' by advising to use that instead for static profiles.

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

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

The description provides concrete usage examples ('What's new with X', 'latest on Y') and explicitly tells when not to use it ('Use entity_profile instead when you want the static profile'). This gives clear guidance on tool selection.

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

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

Annotations provide idempotentHint=true, destructiveHint=false. Description adds context: key-value scoped by identifier, persistence details (authenticated users persistent, anonymous 24hr). No contradiction.

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

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

Five sentences, front-loaded with purpose, no redundant words. Each sentence adds value: purpose, examples, scoping, persistence, pairing.

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 2 params and no output schema, the description fully covers purpose, usage, behavior, and lifecycle. No gaps.

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

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

Schema coverage is 100% with clear descriptions. Description does not add new parameter info beyond the schema, but context for key-value pairs is provided. 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 'Save data the agent will need to reuse later' and gives concrete examples like 'resolved ticker, target address'. It distinguishes itself from sibling tools 'recall' 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 says 'Use when you discover something worth carrying forward' and provides examples. It also mentions pairing with 'recall' and 'forget' to cover the full 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 richly discloses behavior beyond annotations: cascading through multiple lookup endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, returning figi_candidates when ambiguity exists, labeling identifier sources, and explicitly listing unresolved identifiers. This is substantial added behavioral context and does not contradict the read-only/idempotent annotations.

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

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

The description is dense and long, but nearly every sentence contributes operational value, especially since there is no output schema. It is front-loaded with trigger phrases and ends with a useful efficiency note. A slight trim of the enormous parentheticals could improve readability, but it remains appropriately structured for a complex tool.

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

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

Given the tool's complexity, rich annotations, and lack of an output schema, the description covers the essential execution context: supported types, input formats, failure/ambiguity behavior, partial-resolution behavior, and cross-source coverage. An agent has enough information to invoke it correctly and interpret its likely results.

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

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

Schema coverage is already 100%, and the description goes far beyond it with concrete examples (AAPL, 0000320193, CH0038863350), the instruction to pass only the entity name, and detailed warnings about trailing security-class words in bond issuer names. This adds significant meaning for 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's core purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It covers supported entity types and distinguishes the tool as the identity-lookup layer that precedes other tools. This is a specific verb + resource with clear 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?

It explicitly says 'Use FIRST whenever you have a name but need an ID,' giving agents a clear trigger condition. It also details what each supported type can resolve. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds that each entity is probed with ai_visibility_check, results are ranked by score, and returned with score, confidence, and signal density. This adds useful behavioral context beyond the annotations.

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

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

The description is two sentences with a usage example and output description. It is front-loaded with the main action. It is concise but includes a helpful example; could be slightly tighter without losing clarity.

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

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

Given no output schema, the description adequately explains the output format (ranked list with score, confidence, signal density). It explains the tool's inner working (probing with ai_visibility_check). However, it does not explicitly mention the models or context parameters, though those are covered in schema. Overall sufficient for a non-complex tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it only reiterates that entities are probed and gives a usage example. No parameter-specific details are added.

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

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

The description clearly states the verb 'compare' and the resource 'AI visibility across multiple entities'. It differentiates from sibling 'ai_visibility_check' by emphasizing side-by-side comparison and ranking. The usage example solidifies the purpose.

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

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

The description provides clear context for when to use the tool: competitive AI-marketing audits. It implies the sibling tool ai_visibility_check is for single entity checks, but does not explicitly list when not to use it or alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds rich behavioral context: composite nature, partial failures, bundlephobia first measurement delay (5-30s), sources_failed list. No contradiction.

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

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

Description is front-loaded with purpose and packed with details. Every sentence adds value, but could be slightly more concise. However, it efficiently conveys all necessary information in a dense paragraph.

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 composite tool with no output schema, the description thoroughly explains return fields (summary block, per-advisory detail, links, alternative versions), limitations (NPM only, bundlephobia delay), and error handling (sources_failed). Complete given complexity.

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

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

Schema has 100% description coverage for both parameters. Description adds value beyond schema: 'Scoped packages (e.g. @types/node) are accepted' and 'Defaults to the latest published version when omitted'.

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 uses a specific verb 'scan' and resource 'dependency', clearly stating it is a composite check for npm packages. It distinguishes from sibling tools (e.g., deep_research, entity_profile) by focusing on npm ecosystem and combining deps.dev and bundlephobia.

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: 'whenever an agent asks is X safe / popular / small' or 'what does adding lodash cost me'. Also provides exclusion ('NPM ecosystem only in v1') and alternatives ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly').

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 rich behavioral context beyond annotations: it specifies the embedding model (BGE-base-en), similarity measure (cosine), window size (500-char overlapping), character limit (200K chars) with truncation and flagging, and that passages include character offsets for verification.

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 (3-4 sentences) and well-structured: first sentence defines purpose, then usage guidelines, then technical details. 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?

Despite no output schema, the description explains the return value (top-N passages with offsets and similarity scores). It also covers constraints and behavior completely. For a 3-param tool with no nested objects, it is fully informative.

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

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

Schema coverage is 100%, but the description adds meaningful extras: for 'text' it mentions the character limit, for 'query' it provides examples, and for 'limit' it reinforces the range and default. This adds user-oriented context beyond the schema.

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

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

The description clearly states the tool performs 'Semantic search INSIDE a fetched record,' specifying the action (search within), the resource (a fetched record), and the use case (when the record is too big). It distinguishes from siblings like 'ask_pipeworx_grounded' by mentioning pairing.

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 use when the record is 'too big to cram into the prompt' and mentions pairing with 'ask_pipeworx_grounded,' providing clear when-to-use guidance and an alternative.

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

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

Description contradicts annotations: the tool creates new subscriptions each call, implying non-idempotent behavior, yet idempotentHint is true. This is a serious inconsistency. The description adds useful behavioral context (OAuth requirement, SMS cap, webhook details), but the contradiction dominates.

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

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

The description is reasonably concise given the complexity, front-loaded with purpose, and uses bullet-style structure. Minor redundancy in delivery details that are also in the schema, but overall efficient.

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

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

For a creation tool with nested objects and no output schema, the description covers prerequisites, behavior per type, delivery channels, constraints, and return value. It is complete enough for an agent to 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%, and the description adds extensive meaning beyond the schema. It explains each enum value, type-specific params with concrete examples, and delivery object semantics (e.g., webhook HMAC signing, auto-disable).

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 subscription to a live-data event stream and returns a subscription ID. It lists specific types and distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts.

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

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

The description specifies prerequisites (Pipeworx OAuth account), constraints (SMS cap, phone verification), and delivery options. It implicitly contrasts with read-only tools but lacks explicit when-not-to-use instructions.

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, so tool is safe. The description adds behavioral context by explaining the output structure (category-bucketed examples with tool+argument shape) and the argument behavior (full spread vs. focused topic).

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 trigger phrases and clearly organized: use cases first, then output description, then parameter usage. It is reasonably concise given the tool's role as an onboarding gateway, but could be slightly shortened without losing value.

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

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

The description covers the tool's purpose, input, and output (category-bucketed examples with tool+argument shape). No output schema is provided, but the description sufficiently explains what the agent can expect. For a discovery tool with simple input, this is adequate.

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 describes topic as an optional string with a list of allowed values. The description reinforces those values, provides examples ('finance', 'pharma', etc.), and explains the effect of omitting vs. providing the parameter, adding practical usage guidance beyond the schema.

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

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

The description clearly states it is an onboarding entry point for agents that just connected, answering questions like 'what can I ask?' and returning categorized example questions. It distinguishes from siblings like ask_pipeworx and discover_tools by positioning itself as a first-use discovery tool.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and describes optional topic filtering. While it doesn't list exclusions or directly compare to siblings, the usage context is clear and actionable.

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 (destructiveHint=false, readOnlyHint=false), the description adds that the row is deactivated not deleted, and historical events remain via recent_alerts. This fully discloses the behavioral implications.

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, no redundant words, conveys all key information efficiently.

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

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

For a simple tool with one parameter and no output schema, the description covers its action, side effects, ownership constraint, and references sibling tool 'recent_alerts' for historical data.

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

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

Schema coverage is 100%, and the description does not add additional meaning beyond the schema's 'Subscription id (uuid) returned by subscribe.' Baseline 3 is appropriate.

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

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

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

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

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

The description provides usage context by noting ownership enforcement and the deactivation behavior, but does not explicitly state when to use versus alternatives or when not to use.

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

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

Annotations already declare read-only, open-world, and idempotent behavior, but the description goes well beyond by explaining verdict semantics, the meaning of 'could_not_verify' (including the verification_error field), the meaning of 'unsupported', and the citation mechanism. It also warns callers not to treat 'could_not_verify' as evidence, which is critical behavioral guidance.

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

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

The description is long, but every segment serves a purpose: trigger examples, routing rules, return values, error caveats, and efficiency rationale. It is front-loaded with usage triggers and structured with clear distinctions. Slightly verbose compared to the highest-caliber examples, but the density is justified for a tool with complex 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 and the absence of an output schema, the description fully compensates by enumerating the verdict types, the actual value and citation return, reasoning, and the distinct meanings of 'could_not_verify' and 'unsupported'. It also sets expectations about replacing multiple calls, making the tool's role in an agent's workflow clear.

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

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

Schema coverage is 100% and both parameters are documented in the schema. The description adds useful context by tying the tolerance_pct behavior to the claim wording and to the SEC/XBRL exact-percent-delta math, and by giving concrete examples for the claim parameter. Since schema already carries most semantics, this is a solid but not exceptional bonus.

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

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

The description uses a specific verb ('validate') with a clear resource ('claim') and scope ('against authoritative sources'). It opens with natural-language trigger phrases and immediately distinguishes itself from sibling research/search tools by focusing on fact-checking user claims. The mention of replacing 4–6 sequential calls further sets it apart.

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

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

It explicitly states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also describes the two routing paths (structured SEC/XBRL vs grounded pipeline), giving clear context. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of a full when/when-not breakdown.

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