Powo

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive behavior. The description adds value by detailing the return structure (per-model score, confidence, signals, raw_response + combined view) and explaining the default model and BYO key for Anthropic. No contradictions with annotations.

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

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

The description is concise, fitting in two sentences with no redundant words. It effectively communicates the core functionality, parameters, and use cases. Minor improvement could be adding bullet points for readability, but it's well-structured as is.

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 (4 parameters, read-only, no output schema), the description is complete. It covers what the tool does, what it returns, and how to configure it. The annotations provide safety information, so the description focuses on functionality and usage.

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

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

Schema has 100% description coverage, but the description adds practical context: examples for `entity`, supported model values for `models`, the purpose of `_apiKey`, and disambiguation help for `context`. This adds meaning beyond the schema documentation.

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: probing LLMs for visibility of an entity and scoring it. It uses a specific verb ('probe') and resource ('LLMs for visibility'). It distinguishes itself from sibling tools by focusing on AI visibility scoring, not general queries or competitive scanning.

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: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains when to use the `_apiKey` parameter and the default model. However, it does not explicitly state when not to use this tool or mention alternatives, missing some guidance.

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

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

Beyond the annotations, the description discloses meaningful behavior: the tool is an intelligent router that selects the right tool, fills arguments, returns structured answers, and provides stable pipeworx:// citation URIs. It also calls itself 'one fast call' and clarifies that it already routes to live news. It does not mention rate limits or error behavior, but annotations already define the safety profile as 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?

The description is front-loaded with the most important routing decision and remains dense with actionable guidance: prefer over web search, use for factual/current questions, and escalate to grounded or deep research when appropriate. It is longer than strictly necessary because of the extensive domain list and example repetition, but each section adds either scope, usage, or routing information.

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

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

For a broad, high-complexity tool with no output schema, the description covers input style, concrete examples, routing behavior, output characteristics, and escalation paths to relevant siblings. It does not describe failure modes or details of the citation URI format, but an agent has enough context to select the tool and invoke it correctly in most realistic scenarios.

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 documents the 'question' parameter and all five aliases with 100% coverage, so the description does not need to repeat parameter syntax. The description adds contextual value by indicating that the input is natural language and showing examples, though these examples largely mirror the schema examples. This is adequate but not exceptional added value beyond the schema.

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

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

The description clearly identifies the resource and action: it routes a natural-language question across 5,798 tools from 1,517 verified sources, fills arguments, and returns a structured answer with citation URIs. It explicitly contrasts itself with web search and enumerates the domains it covers, so an agent can distinguish it from general search or other siblings.

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

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

The description gives strong when-to-use guidance: 'PREFER OVER WEB SEARCH', specific trigger phrases like 'what is', 'look up', 'find', and concrete examples. It also names explicit alternatives and switching conditions: use ask_pipeworx_grounded for narrow verifiable questions, deep_research for broad/multi-part questions, and notes the built-in live-news routing for breaking news.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond this: it's a full working router (not a stub), behavior may be identical right now, and results feed a merge comparison process. It also explicitly says it 'falls back to nothing' to counter any assumption that beta means degraded.

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

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

The description is compact and information-dense, covering purpose, parity with stable version, current status, usage instruction, and experimental context in five sentences. The first sentence is somewhat long and packs many details, but it earns its place. It could be split slightly for readability but there is no waste.

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

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

Given no output schema and a single-argument input schema with 100% coverage, the description provides everything an agent needs: the tool is a full router, needs a natural-language question, accepts the same shape as ask_pipeworx, is safe to call, and its current behavior is a known quantity. The beta context and comparison outcome are clearly explained.

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

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

Schema description coverage is 100%, and all six parameters are aliases of the single required 'question' parameter. The schema already fully documents that q, text, input, query, and prompt are aliases. The description does not need to add parameter detail because the schema is exhaustive, but it also adds nothing beyond implying the natural-language question payload.

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

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

The description clearly identifies it as the beta variant of ask_pipeworx, a universal router with the same 5,798 tools, arguments, and response shape. It explicitly differentiates itself from the stable ask_pipeworx sibling by framing its role as an experimental edge with candidate routing improvements. The verb 'ask' plus the explicit parallel to ask_pipeworx makes purpose unambiguous.

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

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

The description states precisely when to use it: when you want the newest routing, and tells the agent to use it exactly like ask_pipeworx. It also explains the comparison-to-stable-router context and notes that no candidate is currently active, so current behavior matches ask_pipeworx exactly. This gives an agent confidence about the selection decision.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses refusal behavior, the exact refusal_reason enum, the verbatim evidence field, and the extra LLM call cost. This substantially enriches the agent's understanding of how the tool behaves.

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

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

The description is dense and front-loaded with the core differentiator: 'Hallucination-resistant answer mode.' Every subsequent sentence adds necessary operational or decision-relevant detail, including output shape, refusal semantics, use cases, and cost tradeoff.

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 complete for a complex grounded-answer tool: it explains routing, evidence extraction, return format, refusal conditions, high-stakes use cases, and cost comparison. The input schema covers parameter details, so no critical selection or invocation information 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 description coverage is 100%, and the schema already documents the single question parameter and its aliases thoroughly. The description adds no parameter-specific detail, so the schema bears the responsibility; this is adequate but not enhanced.

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 purpose: a hallucination-resistant answer mode that extracts answers strictly from tool results, distinguished from ask_pipeworx. It identifies the verb ('answers'), the resource ('pipeworx sources'), and the unique behavioral scope ('grounded', refusal on insufficient evidence).

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

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

Explicit when-to-use guidance is provided: 'Use whenever an answer will be quoted, cited, or acted on...' It also gives the when-not-to-use rule: 'prefer ask_pipeworx for casual lookups.' This directly differentiates from 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 indicate read-only, open-world, idempotent, non-destructive. Description adds extensive behavioral detail: fan-out mechanics, response shapes, resolver contract, parent event extractor, news fallbacks, safety checks for low confidence/closed markets/spreads, and resolution rule risk. No contradictions.

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

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

Very detailed, but verbose. Front-loaded with core purpose and usage, then delves into specifics. Each section adds value, but overall length could be reduced while retaining necessary detail.

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

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

Comprehensively covers all aspects: input variations, output shapes, edge cases (closed markets, low confidence, wide spreads, cancellation rules), and response fields. No output schema, but description provides sufficient detail for agent to understand return structure.

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

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

Schema has 100% coverage with descriptions. Description adds meaning by explaining `market` formats, `depth` enum defaults, and `include_raw` usage trade-offs. Provides examples 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 the tool researches Polymarket bets by pulling Pipeworx data. It specifies input formats (slug, URL, question text) and output (evidence packet + comparison). Distinguishes from siblings like polymarket_arbitrage and polymarket_edges by focusing on research.

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

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

Explicitly states use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. Provides classifier examples and fan-out examples. Does not explicitly exclude cases or reference alternatives, but guidance is strong.

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

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

Description adds context beyond annotations: data sources (SEC EDGAR for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. No contradiction with annotations.

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

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

Description is dense but well-structured: starts with trigger phrases, then behavior, data sources, sorting, and output. Every sentence adds value with no redundancy.

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

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

No output schema, but description explains return includes paired data and citation URIs. Covers all necessary aspects for this comparison tool with good annotations.

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

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

Schema covers both parameters (type and values) with full coverage. Description adds meaning: explains what data each type pulls and how values should be formatted (tickers/CIKs vs drug names).

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

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

Description clearly states it performs side-by-side comparison of 2-5 companies or drugs, with specific data points per type. It distinguishes from sibling tools like entity_profile (single entity) and sequential lookups.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups' and provides trigger phrases. It also explains when to use each type (company vs drug).

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

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

The description goes well beyond the readOnly/openWorld/idempotent annotations by disclosing account and plan requirements, latency expectations, gap reporting, the never-invented guarantee, citation resolvability, excerpting behavior, and contradiction scanning. This gives the agent a strong model of what happens when the tool runs.

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

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

The description is dense with useful information but is a long unbroken block with some redundancy around citations and the findings packet. It also contains a garbled, non-functional parenthetical '(Then garbled repeating?)' that detracts from clarity and structure.

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 is remarkably complete: it covers authentication, plan gating, input scope, output fields, gaps, contradictions, citations, timing, and alternatives. An agent has everything it needs to decide when to invoke it and what to expect back.

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

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

Schema description coverage is 100%, and the schema already explains the depth enum and the natural-language question parameter in detail. The description adds helpful context like the paid requirement for thorough and example question shapes, but it does not meaningfully expand parameter semantics beyond what the schema provides.

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

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

The description clearly identifies the tool as 'grounded multi-source research' across named structured data sources, performed in one call with parallel decomposition. It explicitly differentiates itself from open-web search and from ask_pipeworx, making its unique role unmistakable.

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

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

The description gives explicit when-to-use guidance: best for broad/multi-part questions over structured data, with concrete examples. It also names the alternative for single lookups (ask_pipeworx) and the authentication condition under which that alternative should be used instead.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description is not burdened with that base transparency. However, the description adds important nuance: results are 'ready to call directly, no second schema lookup needed', which informs the agent of immediate usability and efficiency.

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 moderately long but well-structured: first sentence states purpose, then enumerates example domains, then explains return value, then gives usage advice. Each sentence adds information. Could slightly trim the list of domains, 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?

No output schema is provided, but the description compensates by fully explaining what the tool returns: 'names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly'. For a discovery tool, this is sufficient context for the agent to understand the response.

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

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

Schema coverage is 100% (all 6 parameters have descriptions). The description adds value by providing examples of natural language queries ('look up FDA drug approvals') and noting that multiple aliases (q, task, search, description) are accepted. This helps the agent understand the flexibility of the query parameter.

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

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

Description starts with 'Find tools by describing the data or task' – a specific verb and resource. It then enumerates domains (SEC filings, FDA drugs, etc.) and explains the return value (top-N tools with names, descriptions, schemas). This clearly distinguishes it from sibling tools that are specific-domain actions.

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

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

Explicitly states 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set'. It provides clear usage context and sequencing advice. Does not explicitly say when not to use, but the guidance is strong enough.

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

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

The description goes well beyond the read-only/open-world/idempotent annotations by disclosing important behavioral details: it fans out across many named sources, returns per-source success/failure flags, treats empty sections as genuine 'no data', resolves names and private companies to resolved:false with a notes line, and explains that lack of small-molecule FDA data is expected. This is rich behavioral disclosure that materially improves invocation correctness.

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

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

The description is extremely dense and runs on in long, semicolon-heavy sentence structures. It contains useful information throughout, but it would benefit from structured bullets or shorter sentences. Some parts, such as the long list of example user phrasings, could be trimmed without losing meaning. It is thorough but not 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?

This is a complex multi-source tool with no output schema, so the description must carry a heavy explanatory burden. It does: enumerating each data source, describing the main return fields, outlining failure semantics, handling private companies, and explaining fallback behavior. An agent has enough context to set expectations 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?

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds value by explicitly stating that 'company' and 'ticker' are interchangeable, that value can be a ticker, zero-padded CIK, or company name, and that name resolution happens via SEC EDGAR. This goes beyond the schema without being redundant.

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

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

The description clearly identifies the tool's purpose: building a holistic, cross-source profile of a US public company in a single parallel call. It uses specific resource language ('company profile', 'full cross-source profile') and the many example user phrasings make the intent unmistakable. It also implicitly differentiates itself from single-pack lookups and sibling tools like resolve_entity by emphasizing the holistic, multi-source aggregation nature.

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

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

The description explicitly states when the tool should be preferred: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also clarifies accepted inputs and expected behavior for private companies, which helps an agent decide when not to use it. This is strong, actionable usage guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description confirms destructive nature but adds minimal extra behavioral context (e.g., no info on idempotency or side effects like what happens if key missing). 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 focused sentences, front-loaded with the core action. Every sentence adds value with 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 delete operation with one parameter and no output schema, the description fully covers purpose, usage context, and parameter role, making it complete.

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

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

The input schema already has 100% coverage with a clear description for the 'key' parameter. The tool description does not add further semantic detail beyond restating that the memory is deleted 'by key'.

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'), the resource ('previously stored memory by key'), and distinguishes it from siblings like 'remember' (store) and 'recall' (retrieve), making the purpose unambiguous.

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

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

Provides explicit guidance on when to use: 'when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier', and advises pairing with 'remember' and 'recall'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. Description adds process details: fetches page, extracts title/description/key links, emits standard llms.txt format. No contradictions.

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

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

Very concise and well-structured: first sentence states purpose, second explains process, third describes output format, fourth lists use cases. Every sentence adds value with 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?

With no output schema, the description adequately explains the return value ('standard llms.txt markdown format', 'single text blob'). Parameters are fully covered. Annotations provide safety profile. 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?

Both parameters are fully described in the schema (100% coverage). The description adds context: default and max for max_links, and explains how url is used (fetches page, extracts content). This goes beyond the schema's basic descriptions.

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

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

Clearly states the tool generates a production-ready llms.txt file for any URL. The verb 'generate' and resource 'llms.txt' are specific. The tool is distinct from all sibling tools, as none directly generate llms.txt files.

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

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

Provides explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor. However, no explicit when-not-to-use or alternatives, though context is clear enough.

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

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

Annotations already indicate read-only, idempotent behavior. The description adds valuable context about the returned data (classification, distribution, etc.), enhancing transparency beyond the annotations.

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

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

The description is three concise sentences, each serving a purpose: action, return details, authoritative note. No redundancy, 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?

For a simple fetch tool with good annotations and single parameter, the description covers purpose, input, and output sufficiently. It misses error handling, but overall 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?

With 100% schema coverage, the baseline is 3. The description adds meaning by explaining the parameter's source (search_plants) and providing an example, improving upon the schema's description.

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

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

The description clearly states the tool fetches a full POWO taxon record by fqId, with an example. It distinguishes from the sibling 'search_plants' by specifying the input as an identifier obtained from that search.

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

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

The description implicitly advises using 'search_plants' first to obtain an fqId, providing clear context. It could be more explicit about when not to use this tool, but the guidance 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 declare readOnly, idempotent, non-destructive. Description adds scope (caller's subscriptions), default behavior (active only), and return fields, adding value beyond annotations.

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

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

Two sentences, no redundant words, front-loaded with purpose and key details.

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

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

For a list tool with no output schema, description explains return fields and scope. Combined with annotations, provides complete understanding for 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 covers the single parameter fully (description for include_inactive). Description does not add extra details beyond schema, so baseline 3.

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

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

Clearly states the tool lists active subscriptions for the caller, specifies returned fields (id, type, etc.), and distinguishes from sibling tools like subscribe/unsubscribe.

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

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

Explicitly advises when to use: 'review what you're monitoring before adding more or to find an id to cancel.' Provides clear context for appropriate use.

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

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

With all annotations false, the description carries the full burden. It discloses the claim_token flow (returned on filing, reusable to check resolution status), the rate limit (5 per identifier per day), cost (free, no quota impact), and team reading cadence. This is far beyond the minimal disclosure and provides concrete behavioral expectations.

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

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

The description is dense but every sentence earns its place: purpose, use cases, exclusions, scope, token workflow, rate limits, and cost. It is front-loaded with the primary intent and flows logically. No filler or redundant content exists.

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 4-parameter tool with no output schema and unhelpful annotations, the description covers all necessary context: when to use, what to report, how the claim_token works, rate limits, and team impact. An agent could invoke and follow up correctly with no further information.

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

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

Schema coverage is 100% and each parameter already has a rich description. The main description adds cross-parameter usage context—how a claim_token is generated from a filing and then used standalone to retrieve status—which goes beyond the individual schema descriptions. However, it doesn't add new per-parameter details, so a 4 is appropriate.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly states it's a feedback tool and enumerates feedback types (bug, feature/data_gap, praise). This differentiates it from sibling tools like ask_pipeworx and deep_research, which are for inquiries/research rather than reporting issues.

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

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

Explicit when-to-use guidance is provided for each feedback type. The description also gives a clear when-not-to-use: for tools from other MCP servers, file with that server instead. It further specifies the scope ('ONLY for tools served by this Pipeworx connection') and content guidelines ('don't paste the end-user's prompt').

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable behavioral traits: caching behavior (5min-1h depending on window), derivation from CF analytics-engine, and privacy guarantee (no PII). This goes 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?

First sentence immediately conveys purpose. Remaining sentences are efficient, adding context without redundancy. No filler.

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

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

For a tool with one optional parameter and no output schema, the description covers all needed information: what it returns, source, caching, privacy, and use cases. Annotations further confirm safety and behavior.

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

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

Schema has 1 parameter with enum and 100% coverage. Description adds strategic guidance: shorter windows for current trends, longer for steady-state demand. This provides meaning beyond the schema.

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

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

Clearly states the tool returns trending data (top tools, packs, call volume) from other AI agents on Pipeworx. Unambiguously distinguishes itself from sibling tools by focusing on aggregate trending signals rather than specific queries or actions.

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: discovering hot data sources, confirming a tool is canonical, and aligning use case with demand. Provides clear context for when to use this tool over others.

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

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

Annotations indicate safe, idempotent, non-destructive behavior. Description adds crucial behavioral details: partition filter, semantic anchor for cross-event pairs, fill check against live CLOB depth, and conditions for null signals. No contradiction.

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

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

The description is dense but every sentence adds value. It front-loads the main purpose and modes, though it could be better structured with bullet points or clearer separation of concepts.

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

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

Despite no output schema, the description thoroughly explains return fields (opportunities, partition_check, fill_check details) and covers edge cases (low similarity, placeholder filters, book depth). Complete for the tool's complexity.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds value beyond schema by clarifying that event accepts full URLs and topic searches related events, and by explaining the difference in behavior.

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 finds arbitrage opportunities on Polymarket using monotonicity violations and partition-sum checks. It distinguishes three modes (trending_scan, event, topic) with specific use cases, fully differentiating from sibling tools.

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

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

Explicit guidance on when to use each parameter: no args for trending_scan, event for specific market, topic for cross-event scanning. Also notes when not to trade (realizable_edge_pp ≤ 0) and references polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: caching strategy ('Cached 1h at the KV level keyed on all knobs'), detailed model families, edge calculation including slippage, and diagnostic output for empty segments. 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 thorough and well-structured, front-loading the overall purpose before diving into model segments and knobs. Every sentence adds value given the tool's complexity. However, it is verbose; a more concise breakdown could improve readability without losing essential details.

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

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

Given the tool's complexity (9 parameters, no output schema), the description explains the full response structure, including three segments, Fed candidates note, diagnostics, and caching. It covers return values, behavioral traits, and parameter usage comprehensively, leaving 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 description coverage is 100%, so baseline is 3. The description adds value by explaining parameter interactions (e.g., min_partition_leg_kelly vs min_kelly, slippage_pp rationale) and providing context like 'Skips opportunities that are too small to bet sensibly even if the edge is large.' This extra context justifies a score above baseline.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where data disagrees with market price. It uses specific verbs ('scan', 'return') and defines the resource ('top Polymarket markets'). It distinguishes from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by specifying unique model families and output structure.

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 context: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It explains tradeable-edge knobs and mentions Fed candidates are excluded from ranking due to data limitations. However, it lacks explicit guidance on when not to use this tool versus alternatives like polymarket_arbitrage.

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: snapshots are written on cache-miss causing gaps, history bounded by 60-day TTL, decay computed from daily closes (not intraday). No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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 slightly verbose. It is well-structured with a clear question, parameter explanation, response breakdown, and limits. Could be trimmed slightly 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?

Given no output schema, the description fully explains the response structure (tracked, expired, snapshot_dates) with field details. It covers complexity: trend, decay rate, lifespan, and limitations. No missing context.

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

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

Schema coverage is 100%; description enhances each parameter with defaults, clamping, and snapshot family names. For example, 'days (lookback, default 14, max 30)' adds clamping info not in schema, and 'window' lists possible values with default.

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: 'Edge persistence and decay telemetry' answering how long an edge has existed and if it's shrinking. It specifies the source (daily polymarket_edges snapshots) and distinguishes the tool from siblings like polymarket_edges by focusing on time-series analysis.

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

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

The description explains when to use this tool: to differentiate between fresh and old edges. It does not explicitly state when not to use or list alternatives, but the context and contrast with 'a fresh wide edge and a 3-week-old wide edge are different trades' imply usage for historical decay analysis.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about ladder walking, return fields (e.g., slippage_pp, verdict), and critical warnings about forced directional risk and thin books, going beyond annotations.

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

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

The description is long but well-structured with capitalized mode headings and clear separation. Every sentence adds value, though the length could be slightly trimmed for brevity. The first sentence delivers the core purpose immediately.

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 enumerates all key return fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict, etc.) and covers edge cases (thin legs, forced directional risk). It is fully adequate for an agent to understand output.

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

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

Schema coverage is 100%, but the description adds significant meaning: explains single-market vs basket mode, default values for side and size_usd, interpretation of size_usd for buys vs sells, and the auto-detection logic for side in basket mode. This is more than what schema provides.

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

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

The description clearly states it performs a realizable-vs-theoretical edge check against live CLOB order-book depth, and distinguishes between single-market and basket modes with detailed expected outputs. It relates to sibling tools, making the purpose unambiguous.

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', and explains why (theoretical overround not capturable, partial fills create directional risk). Provides clear when-to-use guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior, and the description vastly exceeds this baseline by disclosing that pairs are keyword-matched rather than source-verified, that compatibility_codes[] can be non-empty even when matched_pairs>0, that temporal_alignment null means 'could not be computed', and that spread_pp is gross because Kalshi fees are not modeled. This gives the agent a realistic model of the tool's limitations.

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 the complexity justifies it: multiple modes, safety codes, matched flags, skipped counters, and fee disclosures are all important. It is organized with clear labels like TWO MODES, RESPONSE, SAFETY FIELDS, and CODE descriptions, making it scannable. Some sentences are dense and parenthetical-heavy, so it is not maximally concise, but every sentence carries real operational value.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: top_spreads_pp, per-entry flags, compatibility fields, temporal_alignment semantics, skipped_unclassified, low_confidence_pairs, skipped counters, and the fees_note. It also warns the agent about the rarity of real cross-venue spreads and the unreliable nature of pre-mapped topics, which is critical contextual completeness for a tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful operational semantics beyond the schema: the explicit ticker/slug parameters override the topic-mapped side, both modes run the identical matcher, and it explains which mode is appropriate for custom pairings. This is useful but not dramatically beyond the schema's already clear parameter descriptions.

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

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

The description names a specific verb and resource combination: it reports the cross-venue spread between Kalshi and Polymarket for the same resolving question. It also disambiguates itself from sibling tools by emphasizing that this is a gross spread, not a net tradeable edge, and that pre-mapped topics are not automatically tradeable.

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

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

The description clearly explains the two invocation modes — pre-mapped `topic` shortcuts versus explicit `kalshi_event_ticker` + `polymarket_event_slug` — and states that both modes run the same matcher. It also gives practical cautionary guidance such as 'pre-mapped ≠ tradeable' and that most topics currently return compatibility warnings, but it does not explicitly compare against a specific alternative sibling tool for when not to use this tool.

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

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

Annotations already provide read-only, idempotent, non-destructive hints. Description adds value with scoping to identifier (anonymous IP, BYO key hash, account ID).

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, well-structured, no wasted words. Front-loads the core action.

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

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

For a simple read-only tool with one optional parameter, the description fully covers usage, scoping, and pairing with siblings. No output schema needed.

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

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

Input schema covers the single optional parameter with description. The description does not add meaningful detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

Clearly states it retrieves a value saved via remember or lists all keys if omitted. Distinguishes 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 says when to use (look up context stored earlier) and implies when not to (avoid re-deriving). Also mentions scoping and pairing with remember/forget.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by disclosing that setting mark_read:true flags events as read, affecting subsequent calls. It also notes the feed is persisted. 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 tightly written sentences: first states purpose, second lists return fields and filters, third covers the side effect and alternative endpoint. No redundant words; all information earns its place.

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

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

Given the tool has 5 optional parameters, no output schema, and annotations covering safety, the description is largely complete. It explains return values, filtering, and side effects. Minor omission: the 'unread_only' parameter is not elaborated beyond the schema. Still adequate for effective tool selection and 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% with parameter descriptions. The description enhances understanding by providing examples (e.g., 'sec_8k' for type, ISO timestamp for since) and explaining the effect of mark_read. This goes beyond the schema's basic descriptions.

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

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

Description opens with a specific verb+resource ('Pull fired events from your subscription feed') and details the return fields (source, citation_uri, raw payload). It clearly states filtering capabilities and distinguishes itself from siblings like 'recent_changes' by focusing on alerts from a subscription 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?

Provides explicit context for when to use the tool (e.g., 'Polls work fine') and mentions an alternative access method (direct GET endpoint for scripts/dashboards). It explains the mark_read behavior but does not explicitly state when NOT to use this tool versus other options.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. Description adds significant behavioral details: fan-out to multiple sources, fallback from GDELT to GNews, soft-fail for USPTO, and return structure with citation URIs. No contradiction with annotations.

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

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

The description is information-dense but well-structured: starts with usage examples, then source details, parameter guidance, and sibling comparison. Slightly long but every sentence adds value, earning its place.

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

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

Despite no output schema, the description fully covers return format (changes[] grouped by source, total_changes count, citation URIs). Given the tool's complexity (multiple sources, fallbacks, soft-fails), the description provides complete contextual information for the agent.

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

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

Schema coverage is 100%, so the description adds extra value with examples for 'since' (e.g., '7d', '30d', '1y') and specifies typical monitoring use. Clarifies 'value' accepts ticker or CIK. This goes beyond the schema's basic descriptions.

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

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

The description uses specific verbs ('change feed') and clearly states the resource (company) and time window. It explicitly distinguishes from sibling tool 'entity_profile' by stating when to use the alternative 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?

Provides explicit guidance on when to use this tool vs. entity_profile, and gives example queries. Does not explicitly list scenarios where the tool should not be used, but the alternative is clearly stated.

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 beyond annotations: key-value pair scoped by identifier, persistent memory for authenticated users, 24-hour retention for anonymous. Idempotent hint is consistent with description of storing by key.

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

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

Concise paragraph, front-loaded with purpose. Every sentence adds value (use cases, pairing, retention). 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?

Complete for a simple key-value store: explains scope, retention, and relationship to recall/forget. No output schema needed.

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

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

Schema already covers both parameters with examples. Description adds little beyond schema's own descriptions. Baseline 3 is appropriate.

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

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

Clearly states the tool saves data for reuse, with concrete examples (resolved ticker, target address, etc.). Distinguishes from siblings 'recall' and 'forget' 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?

Explicitly describes when to use: 'when you discover something worth carrying forward'. Mentions pairing with recall and forget, providing clear context for alternatives.

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

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

The description adds substantial behavioral context beyond the readOnly/idempotent annotations: it discloses internal cascading across lookup endpoints, graceful degradation when GLEIF or OpenFIGI is unavailable, and the specific sources and outputs (EDGAR, GLEIF, OpenFIGI, RxNorm, pipeworx citation). This meaningfully helps an agent understand side effects and failure behavior, and does not contradict 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 but poorly structured: a single long paragraph with deep parentheticals, uppercase emphasis, and many embedded clauses. It front-loads the core purpose and examples, so it is not uselessly verbose, but it could be significantly more scannable with bullets or shorter sentences.

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

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

Given there is no output schema, the description compensates by specifying the returned identifiers and citations, supported entity types, accepted input formats, source coverage, and fallback behavior. It covers edge cases like non-US issuers and non-equity instruments, making the tool sufficiently complete for correct invocation.

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

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

The input schema already covers both parameters with descriptions, so the baseline is 3. The description goes beyond the schema by explicitly adding ISIN as an accepted company input, explaining how non-equity instruments resolve via name search, and clarifying that drug lookups accept brand or generic names. This is useful additional semantics.

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 resolves user-spoken entity names into canonical identifiers required by other tools, and enumerates supported types ('company' and 'drug') with specific identifier outputs. It positions the tool as a name-to-ID lookup but does not explicitly name sibling tools for contrast, so it is clear but not fully differentiated by sibling comparison.

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

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

The description gives an explicit use trigger: 'Use FIRST whenever you have a name but need an ID.' It also explains supported input forms and graceful degradation, which helps an agent decide when to call it. However, it does not mention alternatives or when not to use it, so it lacks the full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, and signal density. 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 three sentences, each delivering key information: what the tool does, how it works, and its use case. It is front-loaded with the core action and avoids superfluous content.

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

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

The description covers the main purpose, mechanism, and output (ranked list with score, confidence, signal density). Given the tool has four parameters and no output schema, the description is fairly complete, though it does not mention error handling or limitations.

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

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

Schema coverage is 100% with descriptions for all four parameters. The description adds mild value by noting the first entity is treated as the 'subject' for narrative and rest as competitors. This adds context but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. The verb 'compare' and resource 'AI visibility across multiple entities' are specific and distinguish it from siblings like ai_visibility_check (single entity) and compare_entities (generic comparison).

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 use case ('useful for competitive AI-marketing audits') and gives an example question. It does not explicitly state when not to use this tool or list alternatives, but the context implies it's for multi-entity comparison, differentiating it from single-entity tools.

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

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

Annotations already declare readOnly, idempotent, etc. Description adds significant behavioral context: fans out to external services, partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, sources_failed lists timeouts. No contradictions.

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

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

Description is packed with useful information and front-loaded with purpose and usage. Some sentences could be tighter, but overall efficient for the complexity level.

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 (composite, external services, partial failures, multiple output fields) and absence of output schema, the description thoroughly covers behavior, output structure, timing caveats, and ecosystem limitations.

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

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

Schema coverage is 100%; description adds only minor additional context (scoped packages accepted, version defaults to latest), largely repeating schema descriptions. Meets baseline for high coverage but adds little extra value.

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

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

The description clearly states it is a composite check for evaluating whether to add an npm package, fanning out across deps.dev and bundlephobia. It distinguishes from sibling tools by focusing on npm dependencies and listing specific output fields.

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 provides when to use (e.g., agent asks about safety/popularity/size) and when not to use (non-npm ecosystems, with alternative suggestion). Covers both inclusion and exclusion criteria.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is keyless and specifies return fields (family, rank, acceptance status, fqId), going beyond annotations without contradiction.

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

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

Three sentences efficiently convey the database, query type, return fields, and relationship to sibling tools. No redundant words; all sentences earn their place.

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

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

Given no output schema, the description lists key return fields and provides usage workflow. Annotations cover idempotency and safety. For a search tool with simple parameters, this is fully 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?

Input schema covers both parameters with descriptions (100% coverage). The description adds workflow context by explaining the fqId can be passed to get_taxon, which enhances the semantic meaning beyond the schema alone.

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

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

The description clearly states the tool searches POWO for accepted plant names and synonyms by scientific or common name. It specifies the authoritative database and distinguishes from siblings by noting it complements GBIF/iNaturalist with curated taxonomy. No ambiguity.

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 context on when to use (keyless, authoritative taxonomy) and hints at workflow (fqId for get_taxon), but does not explicitly exclude alternative tools or state when not to use it.

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

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

Discloses embedding model (BGE-base-en), similarity metric (cosine), windowing (500-char overlapping), and 200K char cap with truncation flagging. Annotations already declare idempotent and read-only, 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 paragraphs: first explains core purpose and use case, second adds technical details. Every sentence adds value, no fluff.

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

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

Despite no output schema, description fully explains return type (passages with offsets and scores), covers behavior, parameter details, and integration with sibling tool. 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?

Schema coverage is 100%, so baseline 3. Description adds value by providing concrete query examples (e.g., 'supply-chain risk'), clarifying the text max length (200K chars), and specifying limit range and default (1-20, default 5).

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

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

Description clearly states it performs semantic search inside a fetched record, returns passages with offsets and similarity scores. Distinguishes from siblings by mentioning it pairs with ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and describes how it saves context. Recommends pairing with ask_pipeworx_grounded for grounding over relevant passages.

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 fully explains the creation behavior, requirements (OAuth, phone verification), delivery channel nuances (feed always on, email/SMS/webhook with details on webhook signing and auto-disable after 10 failures), and does not contradict any annotation (readOnlyHint=false, idempotentHint=true, etc.).

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

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

The description is well-structured and informative, but could be slightly more concise. However, every sentence adds necessary context, and it effectively front-loads the core purpose.

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

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

Given the tool's complexity (multiple types, nested params, delivery options), the description covers all essential aspects: action, types, params, delivery behavior, security, and limitations. No output schema exists, but the return value is stated.

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 value by providing concrete examples for each subscription type and explaining each delivery field's format, requirements, and limitations (e.g., SMS 10/day cap, webhook HMAC signing).

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It lists supported types and delivery channels, distinguishing it clearly from sibling tools like list_subscriptions 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 provides clear context on when to use (proactive monitoring) and prerequisites (Pipeworx OAuth account, phone verification for SMS), but does not explicitly mention when not to use it or compare to alternatives like list_subscriptions or unsubscribe.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that it draws from a live catalog and returns example questions with tool+argument shapes, which enhances understanding 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 somewhat long but well-structured with examples and options. It is front-loaded with example queries. Every sentence provides useful information, though a minor reduction in length could improve conciseness.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and rich annotations, the description covers purpose, usage, parameters, and output expectations. It is sufficiently complete for an agent to decide and invoke correctly.

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

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

Schema coverage is 100% for the single optional parameter. Description adds value by listing possible topic values (finance, pharma, etc.) and explaining the effect of omitting the parameter, going beyond the schema's description.

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

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

The description provides a specific verb and resource: returns category-bucketed example questions for onboarding. It clearly distinguishes itself from siblings like ask_pipeworx or discover_tools by being the 'onboarding entry point' and includes explicit example queries.

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

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

Explicitly advises 'Use this FIRST' when the agent does not know what Pipeworx can do, and mentions learning to call meta-tools. Could be stronger on when not to use it, but the guidance is clear and action-oriented.

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: it clarifies that the operation is not truly destructive by explaining 'deactivated (not deleted)' and that historical events remain. This aligns with destructiveHint=false and idempotentHint=true, with no contradiction.

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

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

Three sentences, each essential: action, ownership constraint, and behavioral effect. Front-loaded with verb 'Cancel' and resource. No redundant information.

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

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

For a simple one-parameter tool without output schema, the description adequately explains the mutation semantics, ownership, and impact on historical data. No gaps 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?

The input schema has 100% description coverage for the single parameter 'id'. The description does not add additional meaning beyond what the schema already provides, so baseline score 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 it cancels a subscription by id, with specific verb 'Cancel' and resource 'subscription'. It distinguishes itself from related tools like subscribe and list_subscriptions.

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

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

The description explicitly mentions ownership enforcement and that only own subscriptions can be cancelled. It explains that the row is deactivated rather than deleted, providing clear context on when to use. However, it does not explicitly mention when not to use or provide direct alternatives.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses crucial behavioral semantics: the distinction between could_not_verify (verification did not happen, with verification_error) and unsupported (no source covers it), the tolerance_pct override behavior, and the return of verbatim evidence with citations. These details tell the agent how to interpret results safely and are not available from annotations alone.

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

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

The description is longer than typical but every sentence contributes: trigger phrases, use case, financial vs. other routing, return value summary, caller-important error semantics, and efficiency rationale. It is front-loaded with the most likely queries. Some redundancy exists (e.g., the phrase examples and 'replaces sequential calls' line could be trimmed), so it's not a perfect 5.

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

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

The tool has no output schema, so the description must explain return values and edge cases, and it does: it enumerates the six verdict types, states that evidence and citation are included, and elaborates on the meaning of two failure states (could_not_verify vs unsupported). Given the tool's complexity, the description fully covers what the agent needs to invoke it 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?

While the schema already documents both parameters (100% coverage), the description adds significant semantics: it clarifies what kind of natural-language claim fits the claim parameter, defines tolerance_pct's behavior (overrides claim wording, use 1–2 for hallucination detection), and explains the default cap. This goes well beyond the baseline schema.

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

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

The description opens with clear trigger phrases and immediately identifies the tool's purpose: "natural-language claim verification against authoritative sources." It specifies the verb+resource (verifies claims against sources), and the examples of user phrasing make the intended use unmistakable and clearly distinguish it from sibling tools focused on search, research, and trading edge detection.

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 the tool: "Use whenever the agent needs to check whether something a user said is factually correct." It further provides routing policy for financial vs. non-financial claims and even notes that this replaces 4–6 sequential calls, giving a strong sense of when this is the right choice. However, it does not explicitly state when not to use it or name alternatives for exploratory or open-ended research, so it misses the top bar.

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