Biosamples

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

Annotations indicate readOnly, openWorld, idempotent, non-destructive. The description adds cost implications (free default, BYO key for Anthropic) and return structure (per-model fields + combined view). 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 concise (3 sentences) with front-loaded purpose. Every sentence provides essential information: what it does, default model, optional API key, return format, and use cases. No redundant or missing 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?

Despite no output schema, the description explains return values sufficiently (per-model {score, confidence, signals, raw_response} + combined view). It covers all aspects for a probing tool with 4 parameters and full schema descriptions.

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 parameters are documented. The description adds value by naming the default model ('Workers AI Llama-3.3-70b'), clarifying payment for Anthropic, and explaining the optional context parameter's purpose.

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 brand visibility and scoring it 0-100. It uses specific verbs ('probe', 'score') and resource ('LLMs'). It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on visibility scoring across multiple models.

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

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

The description provides explicit use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to use the default model vs Anthropic with a BYO key. It lacks explicit when-not-to-use or alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context beyond those: the routing/fan-out behavior, argument auto-filling, the stable 'pipeworx://' citation URIs in the return value, and the 'works on every tier, one fast call' performance note. No contradiction with annotations.

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

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

The description is dense and front-loaded, opening with the most important directive ('PREFER OVER WEB SEARCH') followed by the core purpose. Every sentence earns its place: domain list, triggers, examples, tier note, and alternative routing all serve distinct decision points. It is longer than minimal, but the length is justified by the tool's broad scope and the routing decisions an agent must make.

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

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

For a complex routing tool with no output schema, the description is remarkably complete: it covers when to use it, when not to, what it returns (structured answers with citation URIs), its domain coverage, its cost/performance profile, and the exact conditions for stepping up to grounded or deep_research. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents the question parameter and all five aliases with examples. The description implies the argument should be natural-language and covers factual scenarios, and mentions the tool 'fills arguments' itself — a useful hint that the agent need only supply a question. But it adds no syntax or format detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('routes the question'), a specific resource (5,724 tools across 1,497 verified sources), and enumerates concrete data domains (SEC filings, FDA drug data, FRED/BLS economics, patents, etc.). It names the sibling tools it is not (ask_pipeworx_grounded, deep_research), so an agent can differentiate them without opening other schemas.

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

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

Exceptional guidance: explicitly says 'PREFER OVER WEB SEARCH', lists trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), gives six concrete examples, and states exactly when to step up to alternatives ('for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'). Nothing is left to inference.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses the experimental nature, that candidate routing improvements are enabled live when under test, and that no candidate is currently active so behavior matches ask_pipeworx. It clearly warns this is the 'experimental edge' and a full working router. This adds valuable context 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 dense with useful information and every sentence contributes. It is front-loaded with the beta identity and relation to ask_pipeworx. Some redundancy exists (e.g., 'Falls back to nothing' and 'this IS a full working router'), but the overall structure is 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?

Given the tool's complexity as a router to thousands of tools and no output schema, the description covers the critical aspects: what it is, how it relates to the stable version, current experimental state, and behavioral expectations. It could mention potential differences when a candidate is active more prominently, but the current state is clearly described.

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 all 6 parameters with 100% coverage, including aliases for question. The description only repeats 'same arguments' without adding new semantic detail. Baseline 3 is appropriate since the schema carries the full burden.

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 ask_pipeworx_beta is a beta version of ask_pipeworx, a universal router to 5,724 tools, and explicitly distinguishes it from the stable router. It uses specific language ('identical universal router', 'same response shape') that makes the tool's purpose unambiguous and differentiates it from the sibling ask_pipeworx.

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

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

The description gives explicit use guidance: 'Use it exactly like ask_pipeworx when you want the newest routing'. It also implies the alternative (stable ask_pipeworx) and explains that results are compared to the stable router. However, it could more explicitly state when not to use the beta, such as preferring the stable version for production or critical tasks.

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, and idempotent hints. The description goes further by explaining the exact success response shape, the refusal structure with specific refusal_reason values, and the fact that extraction uses ONLY tool result content. This fully discloses the behavioral contract 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 longer than average but every clause earns its place: purpose, routing mechanism, response schema, refusal reasons, use cases, and cost tradeoff are all relevant. The main purpose is front-loaded, though slightly dense.

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?

Even though there is no output schema, the description fully explains what the tool returns on success and failure, including refusal_reason enums. It covers cost, routing, and when to prefer an alternative, making the tool self-sufficient for an agent.

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

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

Schema coverage is 100% — the schema already documents the single 'question' parameter and all aliases. The description does not add new parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb ('ask'), a distinct mode ('grounded'), and a precise resource context (5,724 tools across 1,497 sources). It clearly differentiates from ask_pipeworx and ask_pipeworx_beta by emphasizing hallucination resistance and evidence-grounded answers.

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

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

Explicitly states when to use (answers that will be quoted, cited, or acted on; high-stakes financial, legal, or medical claims) and when not to use (casual lookups). It even names the cheaper alternative, ask_pipeworx, and the cost tradeoff of one extra LLM call.

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

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

The description adds extensive behavioral details beyond annotations: resolver confidence levels, parent event extraction, news fallback mechanisms, safety short-circuits for low-confidence matches and closed markets, wide-spread handling, and resolution-rule risk. All align with annotations (readOnlyHint, idempotentHint, openWorldHint) 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?

The description is well-structured with clear sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.), but it is excessively long. While the detail is valuable given complexity, conciseness is compromised. The information could be more tightly written without losing meaning.

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, no output schema, and three parameters, the description is remarkably complete. It covers all relevant aspects: parameter usage, response structure, edge cases (low-confidence, closed markets, wide spreads), safety mechanisms, and resolution rules. An agent has sufficient information to use the tool correctly in diverse 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?

Schema coverage is 100%, so the schema documents all parameters. The description adds value by explaining the effect of 'depth' (quick vs thorough) and providing practical guidance for 'include_raw' (when to use true). This surpasses the baseline of 3 for high coverage.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It identifies the specific resource (Polymarket bet) and action (research), and distinguishes itself from sibling tools by focusing on comprehensive bet research with multiple classifiers and data sources.

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

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

Usage guidance is provided: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This gives clear context for when to invoke the tool. However, it does not explicitly state when not to use it or mention alternative sibling tools, which would strengthen this dimension.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing data sources (SEC EDGAR/XBRL for companies, FAERS/FDA for drugs), fiscal year handling, sorting by primary metric, and output including citation URIs.

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

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

The description is front-loaded with common trigger phrases and well-organized. It is slightly verbose but each sentence adds unique value, covering purpose, usage, data details, and output format.

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

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

Given no output schema, the description adequately describes return values (paired data + citation URIs). It covers inputs, data sources, sorting, and the efficiency advantage, making the tool fully understandable.

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 meaning by explaining what data each type pulls (e.g., revenue, net income for companies), reinforces value format (tickers/CIKs vs drug names), and mentions the 2–5 constraint.

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 specifies the tool performs side-by-side comparisons of 2–5 companies or drugs in one parallel call. It lists example queries and distinguishes from siblings like entity_profile which handles single entities.

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

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

Explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing clear when-to-use guidance. Details input constraints such as 2–5 entities and format for tickers or drug names.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, but the description goes well beyond them. It discloses the parallel routing through 5,724 tools, the findings packet shape (verbatim evidence + confidence + source + fetched_at + citation), the gaps[] never-invented guarantee, contradictions[], hop fields, citation_uri resolvability, semantic excerpting, latency expectations, and the paid tier requirement for thorough depth. No contradiction with annotations.

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

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

The description is long, but it is front-loaded with the account constraint, usage guidance, and the central differentiator ('this is NOT open-web search') before diving into behavioral specifics. Every sentence carries distinct information about sources, output shape, depth semantics, or latency. Minor trims could tighten it, but the length is largely justified by the tool's complexity.

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

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

There is no output schema, so the description carries the full burden of explaining return values—and it does so thoroughly: findings packet fields, citations, gaps[], contradictions[], hop field, and semantic excerpting. It also covers auth prerequisites, depth differences, latency, and when not to use the tool. An agent has everything needed to select, invoke, and interpret the 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 schema already covers both parameters at 100% coverage, and the description adds meaningful context on top: it explains the depth enum in operational terms (quick=3 facets single-hop, standard=3 with gap recovery, thorough=6 with iterative chasing) and clarifies that the question parameter is intended for broad/multi-part queries. This adds practical semantics beyond the per-value schema text.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1497 STRUCTURED data sources... in ONE call' and immediately distinguishes itself from open-web search and from sibling ask_pipeworx (single lookup vs. multi-facet research). It also explains the decomposition and parallel-tool behavior, leaving no ambiguity about what the tool does.

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

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

Explicitly states when to use it: 'Best for broad/multi-part questions over structured data,' and when not to: 'For a single lookup use ask_pipeworx' and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx.' It also names the account-requirement fallback ('If you are not signed in, use ask_pipeworx instead'). This is exemplary routing guidance with named alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond annotations by explaining that the tool returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly', which informs behavior.

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

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

The description is front-loaded with purpose and uses two main sentences plus a list of domains. It is efficient but could be slightly more concise by trimming domain list length.

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

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

Given no output schema, the description fully explains what is returned (tool names, descriptions, schemas). It covers the input parameters and provides usage examples. For a tool with moderate complexity (6 params, aliases), this is complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by stating that the query accepts natural language, lists example queries, and mentions aliases (though schema already documents them). This provides meaningful extra guidance.

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

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

The description clearly states 'Find tools by describing the data or task' and enumerates specific domains (SEC filings, FDA drugs, etc.), distinguishing it from sibling tools like search_samples or deep_research by emphasizing that it returns tool definitions ready to call.

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

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

The description explicitly says 'Call this FIRST when you have many tools available and want to see the option set', providing strong usage context. However, it does not explicitly state when not to use this tool or name specific alternatives.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral context: it fans out across multiple sources in parallel, soft-fails for patents (May 2025 sunset), and provides specific return fields. 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 somewhat verbose but well-structured, with front-loaded example queries and a clear list of return fields. Every sentence adds value, though it could be slightly tighter. Still, it is efficient given the complexity.

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

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

Given the tool's complexity (multi-source, no output schema), the description is very complete. It covers return fields, source details, limitations (patents sunset, name handling), and example inputs. The agent has sufficient context to invoke the tool correctly.

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

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

Schema coverage is 100%, and the description enriches parameter meaning significantly. It clarifies that 'value' accepts ticker or zero-padded CIK but not names, and that 'type' only supports 'company' for now. This adds practical guidance beyond the schema.

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

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

The description clearly states the tool provides a full cross-source profile of US public companies in one parallel call, listing specific sources and return fields. It distinguishes from siblings by explicitly recommending this tool over chaining single-pack lookups and referencing related tools like compare_entities and resolve_entity.

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

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

The description gives explicit example queries for when to use the tool and advises to prefer it over chaining separate lookups. It also specifies limitations: names not supported, use resolve_entity first, and notes the patents API sunset. This provides clear when-to-use and when-not-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 destructiveHint=true and readOnlyHint=false. Description adds context about clearing sensitive data, enhancing transparency beyond annotations. No contradiction.

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

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

Two sentences, front-loaded with action ('Delete a previously stored memory by key'), no unnecessary words. Efficient and 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 tool with one parameter, no output schema, and comprehensive annotations, the description covers all necessary context effectively.

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

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

Schema coverage is 100%, so schema fully documents the 'key' parameter. Description does not add further semantics beyond what is in the schema, meeting baseline but not exceeding.

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

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

Description clearly states the tool deletes a memory by key, using verb 'delete' and resource 'memory'. It distinguishes from siblings 'remember' and 'recall' which store and retrieve respectively.

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

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

Explicitly lists when to use: stale context, task completion, clearing sensitive data. Also suggests pairing with 'remember' and 'recall', providing guidance on alternatives.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds detail on fetching the page, extracting content, and output format, which complements 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?

The description is a single, front-loaded paragraph without wasted words. It efficiently conveys purpose, process, and use cases. Minor improvement could be bullet points for clarity.

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

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

Given the tool's simplicity, the description covers purpose, process, output, and use cases. No output schema exists, but annotations compensate. Complete enough for an AI 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?

Both parameters have schema descriptions (100% coverage). The description does not add further meaning beyond what the schema provides, so baseline score applies.

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

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

The description clearly states the tool generates a production-ready llms.txt file, specifies the process (fetch, extract, emit), and includes distinct use cases. It differentiates from siblings by its unique function.

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 (client indexing, own project, competitor audit) but does not mention when not to use or alternatives. Given no direct siblings, this is sufficient.

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

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

Annotations already declare read-only and idempotent. The description adds that the tool returns specific fields (name, dates, taxId, organism, characteristics) and notes it is 'keyless', which is useful context beyond annotations.

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

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

Two sentences with no fluff. First sentence states purpose, second lists return fields. Perfectly concise and front-loaded.

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

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

For a simple fetch-by-accession tool with no output schema, the description covers the purpose, input format, and output fields. No missing context given the low complexity.

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

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

The schema already fully describes the accession parameter with examples. The description's mention of accession format repeats the schema's description, adding no new semantic value. Baseline 3 due to 100% schema coverage.

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

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

The description clearly states the tool fetches a single EBI BioSamples record by accession, specifying the source, action, and identifier. It also lists return fields, distinguishing it from the sibling 'search_samples' tool.

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

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

While not explicitly stating when to use vs alternatives, the purpose is clear: use this tool when you have a specific accession and need full record details. The sibling 'search_samples' implies a search function, so context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. Description adds return field details but does not contradict 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, directly stating purpose and usage. No unnecessary words.

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

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

With one optional parameter, no output schema, and rich annotations, the description is sufficient. It lists return field names, providing helpful 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%, and the schema describes the only parameter (include_inactive) with a clear description. The description adds no additional parameter info, 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?

The description clearly states the tool lists the caller's active subscriptions and lists the return fields. It distinguishes from siblings like 'subscribe' and 'unsubscribe'.

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

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

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

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

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

Annotations are all false hints, providing no positive safety/behavior profile, so the description carries the full burden. It discloses rate limiting (5/day), quota exemption, return of a claim_token, the follow-up mechanism with the token, and the team's daily review process—substantial behavioral context beyond annotations.

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

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

The description is longer than average but every sentence adds operational value (usage, exclusions, token workflow, rate limits). It is front-loaded with purpose and usage, then proceeds to behavioral details. Slightly dense but appropriately so for a tool with a multi-step follow-up workflow.

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

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

Despite having no output schema, the description fully explains the return behavior (claim_token) and the subsequent read flow, which is essential for using the tool correctly. It also covers prerequisites (n/a), constraints, and limitations, making it complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the type categories with concrete examples, clarifying message content ("Don't paste the end-user's prompt"), and detailing how claim_token should be used as a read-the-status follow-up. It doesn't cover the context sub-object, but schema already does that.

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 cleanly delineates the tool's scope and explicitly distinguishes it from siblings by stating it is ONLY for tools served by this Pipeworx connection, not other MCP servers.

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

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

Provides explicit when-to-use guidance: bug, feature/data_gap, or praise. It also gives a clear exclusion (other MCP servers) and a disambiguation heuristic ("Pipeworx tool names are the ones this connection lists"), making it easy to decide between this and alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds key behavioral context: data is self-aggregating from CF analytics-engine, contains no PII, and is cached for 5min-1h depending on window. 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?

The description is concise, front-loaded with the main output, and structured with numbered 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?

For a simple tool with one optional parameter and no output schema, the description is complete. It covers purpose, use cases, data source, caching, and privacy (no PII). The nature of the output (top tools, top packs, volume) is clearly described.

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

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

The single parameter 'window' has full schema coverage and the description adds meaning: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This helps the agent choose the right window.

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 'Returns the top tools, top packs, and total call volume over a recent window.' It uses a specific verb and resource, and distinguishes itself from sibling tools like discover_tools and ask_pipeworx by focusing on trending data.

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

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

The description provides three explicit use cases: discovering hot data sources, confirming canonical tool choice, and checking alignment with other agents. This gives clear when-to-use guidance and implicitly suggests when not to use (e.g., for specific queries).

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive behavior. Description adds extensive context: partition checks, semantic anchor for cross-event, placeholders filter, fill check against live order book depth. 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 detailed but well-structured with distinct sections for each mode and important notes. Could slightly trim redundancy, but it remains readable and front-loaded with key 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?

Given the tool's complexity (three modes, multiple checks), the description is exceptionally thorough, covering response structure, semantic constraints, and edge cases like placeholder filtering. No output schema, but response fields are enumerated.

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

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

Schema description coverage is 100%, providing clear descriptions for both parameters. Description adds extra meaning: event accepts full URLs, topic is a seed question, and explains the mode behavior in depth.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) with specific verbs and resources.

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

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

Explicitly describes when to use each mode: no args for trending scan, event for specific market, topic for cross-event scan. Also advises when not to trade (realizable_edge_pp <= 0) and provides alternatives like 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 mark readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint as false. The description adds extensive behavioral detail beyond annotations: explains the three model families, caching behavior (1h KV cache), diagnostics structure, and tradeable-edge knobs. 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 very long and dense, covering multiple paragraphs of technical details. It front-loads the purpose but could be more structured (e.g., bullet points or sections). The length is justified by complexity, but conciseness could be improved.

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

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

Given the tool has 9 parameters, no output schema, and a complex return structure, the description is exceptionally thorough. It explains the response top-level structure (by_segment, fed_candidates, diagnostics), every model family in detail, and all knobs. It even explains why segments might be empty via funnel counters. Perfectly complete for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining parameter interactions (e.g., min_partition_leg_kelly works on per-leg Kelly) and providing context (e.g., slippage_pp explains Polymarket fee structure). The description compensates for 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 a specific verb 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price', clearly stating the resource and distinguishing purpose. It also explicitly mentions the intended use case 'what should I bet on today' and outlines three distinct model families, differentiating it from sibling tools like polymarket_arbitrage.

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

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

The description explains when to use this tool (discovering opportunities without paging) and provides detailed guidance on how to interpret results and adjust knobs. However, it does not explicitly exclude alternatives or state when not to use, relying on context from sibling names.

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 mark readOnlyHint, idempotentHint, and nondestructive. Description adds details: snapshots have 60-day TTL, decay from daily closes (not intraday), and gaps from cache misses. No contradictions with annotations. Extends transparency beyond defaults.

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

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

Description is detailed but not verbose; each section (purpose, response format, limits) earns its place. Front-loaded with core question, though could trim some repetition (e.g., snapshot dates explanation). Still well-structured and 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, but description comprehensively explains response fields (tracked[], expired[], snapshot_dates[]) with attributes like trend, decay rate, lifespan. Also covers data gaps and TTL limits. Complete for a read-only telemetry tool.

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

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

Schema covers both parameters with descriptions. Description adds additional context: default values, clamp for days, and why window family matters. Adds modest value beyond schema, consistent with baseline for high coverage.

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

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

Description clearly states it provides edge persistence and decay telemetry from daily snapshots, answering a specific question about edge longevity. It distinguishes itself from sibling polymarket_edges by focusing on time-series and decay rather than current edge values.

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

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

Provides context on when to use (to assess edge age and decay), contrasting fresh vs old edges for trade decisions. Does not explicitly list alternatives or when not to use, but sibling tools imply polymarket_edges for current edges, so guidance is adequate.

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, idempotentHint, non-destructive. Description adds valuable context: walks ladder, returns detailed fill metrics (top_of_book, vwap_fill_price, slippage, verdict), per-leg details, and risk analysis (thin_legs, forced_directional_risk). No contradiction with annotations; adds behavioral specifics beyond what annotations imply.

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?

Long but well-structured with embedded headings (SINGLE-MARKET:, BASKET:). Front-loads purpose and usage. Every sentence adds value given the tool's complexity (two modes, multiple return fields). Could be slightly more concise, but the detail is justified.

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, yet description fully documents all return fields for both modes, including risk warnings (partial fills, directional exposure). Covers parameters, behavior, and consequences adequately. For a complex tool with 4 params and no output schema, this is extremely complete.

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

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

Schema coverage is 100% (all 4 parameters described). Description adds significant meaning: clarifies size_usd interpretation differs by mode (spend vs target proceeds vs settlement notional), explains side default logic for baskets (auto from partition sum), and defines market/event requirements. Goes well beyond schema descriptions.

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

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

Description specifies verb ('check') and resource ('realizable-vs-theoretical edge against live CLOB order-book depth'), distinguishes between single-market and basket modes with clear semantics. No ambiguity with sibling tools like polymarket_arbitrage or polymarket_edges.

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage... signal or any polymarket_edges trade above ~$500'. Explains when not to use (theoretical overround not capturable, partial fill risk) and provides alternative tool contexts. Also clarifies required parameters ('REQUIRES one of market or event').

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

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

Even though annotations already declare readOnlyHint/openWorldHint/idempotentHint, the description adds an exceptionally rich behavior picture: safety fields can be non-empty even with matched_pairs>0, compatibility_codes semantics, temporal alignment specifics, a standing fee disclosure stating spreads are gross, and exact handling of unclassified legs. This far exceeds what annotations provide and helps the agent interpret results correctly.

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

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

The description is long, but it earns its length by covering many non-obvious edge cases that cannot be inferred from schema or annotations. It is front-loaded with the core purpose and uses clear mode/response/safety markers. It could be tighter (some repeated references to the same matcher and warnings), which keeps it at a 4 rather than a 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?

There is no output schema, so the description bears the full burden of explaining return semantics — and it does: top_spreads_pp values are Kalshi minus Polymarket, spread.skipped_unclassified and low_confidence_pairs exist, temporal_alignment can be null, and fees are gross rather than net. For a complex comparison tool this is a complete invitation to call it correctly.

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

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

Schema coverage is 100% and explains the topic values, ticker, and slug, so the baseline is 3. The description adds the mode relationship — topic alone OR the explicit pair, with both modes running the same matcher and 'overrides' behavior — which meaningfully helps an agent choose/combine parameters correctly.

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

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

The purpose is unmistakable — it computes a cross-venue probability spread between Kalshi and Polymarket for the same resolving question — and it distinguishes two modes. It does not use an explicit action verb like 'compute' or 'get' in the opening sentence, and it does not contrast itself with sibling tools such as polymarket_arbitrage, but the resource and relationship are specific enough for an agent to know when to call it.

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 concrete usage guidance: use topic for 10 pre-mapped shortcuts, or provide kalshi_event_ticker + polymarket_event_slug for custom pairs, and warns that most pre-mapped topics currently return compatibility_warning and are not necessarily tradeable. It does not name alternative tools or explicitly say when not to use this versus polymarket_arbitrage, so it stops short of a 5.

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

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

Annotations already provide read-only, idempotent, non-destructive hints. Description adds scoping to identifier and the ability to list all keys, providing useful context beyond annotations.

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

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

Three sentences, minimal and informative, no wasted words. Front-loaded with 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 one optional parameter, no output schema, and annotations covering safety, the description fully explains behavior, scoping, and relationship to sibling tools.

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

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

The input schema has 1 parameter with 100% coverage description. The description adds clarity about omitting key to list all keys, adding value beyond schema.

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

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

The description clearly states it retrieves a value saved via remember, or lists all keys if omitted. It 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 mentions pairing with remember and forget. Does not explicitly state when not to use, but context is clear given sibling list.

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

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

The description goes beyond annotations by detailing that returned events include source, citation_uri, and raw payload. It also explicitly discloses the side effect of the 'mark_read' parameter (flags events as read, affecting future calls). This provides crucial behavioral context beyond the readOnlyHint and other 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 four sentences, each serving a distinct purpose: purpose, payload contents, filtering/mark_read behavior, and alternative usage. It is front-loaded with the most critical information and contains no redundant words.

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

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

Given the tool has 5 optional parameters, no output schema, and read-only annotations, the description covers all necessary aspects: what is returned (source, citation_uri, raw payload), how to filter (type, since), the side effect of mark_read, and an alternative access method. This provides a complete mental model for an AI 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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining the effect of 'mark_read' (flagging events so next call only shows newer ones) and providing an example for 'type' ('sec_8k'). It also clarifies that 'since' expects an ISO timestamp, which reinforces the schema description. However, it doesn't add much to 'limit' or 'unread_only' 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 opens with a clear verb-resource pair: 'Pull fired events from your subscription feed.' It immediately specifies the resource and action, distinguishing it from sibling tools like 'list_subscriptions' which lists subscriptions rather than events.

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

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

The description mentions that polling works fine and provides an alternative REST endpoint for scripts/dashboards, which gives guidance on when to use this tool versus an HTTP alternative. However, it doesn't explicitly state when not to use this tool or compare it to other 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?

The description details behavioral traits beyond annotations: fans out to multiple data sources, fallback from GDELT to GNews, USPTO soft-fail until May 2025, and return structure. Annotations already indicate readOnlyHint and idempotentHint, aligning with the description.

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

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

The description is somewhat lengthy but well-structured: it begins with example queries, explains data sources and behavior, then describes input parameters, and concludes with an alternative. Every sentence adds value, though a few details could be slightly more compact.

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 data sources, fallback logic, parameter formats, no output schema), the description completely covers return format (structured changes grouped by source, total_changes count, citation URIs), input behavior, and provides a pointer to the alternative tool 'entity_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?

Schema coverage is 100% with descriptions for all three parameters. The description adds extra meaning by clarifying accepted formats for 'since' (ISO date or relative shorthand), explaining that 'value' can be a ticker or CIK, and noting that 'type' is limited to 'company'. This goes beyond the schema but is not exhaustive.

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

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

The description clearly states the tool provides a change feed for companies covering SEC filings, news, and patents in a specified time window. It uses specific verbs and resources (e.g., 'change feed', 'fans out to SEC EDGAR, GDELT→GNews, USPTO') and distinguishes itself from the sibling 'entity_profile' tool.

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

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

The description explicitly explains when to use this tool (for recent updates over a window) and when not to use it (for static profiles, recommending 'entity_profile' instead). It provides example queries and alternative usage contexts.

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 key behavioral details beyond annotations: key-value scoping by identifier, persistence differences for authenticated vs. anonymous users (24-hour retention). 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?

Efficiently structured: purpose, usage, technical details in 3-4 sentences. No redundancy, every sentence adds value.

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

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

Fully addresses the tool's function, scope, and edge cases given its simplicity (2 params, no output schema). No gaps remain.

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

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

Schema covers 100% of parameters with descriptive examples. Description adds usage context but no additional meaning beyond schema; baseline 3 is appropriate.

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

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

The description clearly states the tool saves data for reuse, with specific examples like 'resolved ticker' and 'user preference'. It distinguishes from sibling tools recall and forget.

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

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

Explicitly describes when to use ('when you discover something worth carrying forward') and mentions paired tools (recall, forget), providing clear context for selection.

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

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description adds meaningful behavioral context: graceful degradation when GLEIF/OpenFIGI is unavailable, internal cascading through multiple lookup endpoints, explicit unresolved results, and the ISIN-to-LEI route for non-US issuers. This goes well beyond what the annotations convey.

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

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

The description is long, but most sentences carry unique information: examples, supported types, degradation behavior, and input-format caveats. It is front-loaded with the most important guidance ('Use FIRST'), though the parentheticals are dense and could be tightened without losing meaning.

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 explains what will be returned: CIK, ticker, company_name, LEI, FIGI candidates, and RxCUI with ingredient and brand. It covers input formats, supported entity types, failure behavior, and scope exclusions, making it complete enough for an agent to invoke this tool correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial semantic value: it expands the accepted input for company to include ISIN, clarifies that drug accepts brand or generic names, and gives a critical usage warning about passing only the entity name rather than the full noun phrase. These details materially improve correct invocation.

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

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

The description states a specific verb-object pair: resolve a user-spoken NAME to canonical/official identifiers that other tools require as input, and names the supported types (company, drug) with concrete examples. This clearly differentiates it from sibling tools like entity_profile or compare_entities by focusing on name-to-ID resolution.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID,' giving clear directional guidance. It also explains that non-equity instruments resolve here and that it replaces 2-3 manual lookups, though it does not name specific sibling tools to avoid or contrast against.

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, idempotent, etc.), the description discloses that it internally calls ai_visibility_check for each entity, returns a ranked list with score/confidence/signal density, and treats the first entity as the subject. 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?

Two concise sentences: first states the core function, second gives a use case and overview of the output. Every sentence earns its place with no redundancy.

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

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

Given no output schema, the description adequately explains the return object (ranked list with score, confidence, signal density) and the process. However, the exact structure per entity could be more explicit.

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 schema coverage is 100%, the description adds value by explaining that the first entity in the array is treated as the subject and the rest as competitors, and that the context parameter disambiguates common names. This goes beyond the schema descriptions.

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

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

The description clearly states the verb ('Compare AI visibility') and resource ('multiple entities'), with explicit differentiation from the sibling tool 'ai_visibility_check' by noting it probes multiple entities side-by-side.

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 a concrete use case ('competitive AI-marketing audits') and implies that for single entities, one should use ai_visibility_check. However, it does not explicitly state when not to use this tool or name alternatives.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. Description adds valuable beyond: mentions graceful degradation, timeouts (5-30s for bundlephobia first measurement), and partial failure reporting via sources_failed.

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 a single dense paragraph. It effectively front-loads the core purpose, then details return structure and caveats. Could be more structured with bullet points, but still concise and informative.

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?

Without output schema, description fully lists return fields (summary block, per-advisory, links, alternative versions), explains ecosystem scope, failure behavior, and timing caveats. No gaps in required context.

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

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

Schema coverage is 100%, so baseline 3. Description adds that scoped packages are accepted and version defaults to latest. However, does not elaborate on other constraints or format details beyond schema.

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

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

Description explicitly states the composite check for npm packages, including the verb 'scan' and resource 'dependency'. It distinguishes from other ecosystem tools by specifying NPM only, and contrasts with siblings like 'comparing entities'.

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

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

Clearly states when to use: when agent asks about safety, popularity, size, or cost of adding a package. Also specifies when not to use: other ecosystems fall under different tools (deps.dev:version).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it returns specific fields (accession, name, organism, release date), but does not detail additional behaviors like rate limits or pagination limits beyond the schema.

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

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

The description is two efficient sentences, front-loaded with the core purpose. 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?

With 100% schema coverage, rich annotations, and no output schema needed, the description covers the tool's functionality well. It could mention pagination behavior beyond defaults, but it's not essential.

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

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

Schema coverage is 100% with clear parameter descriptions. The description reinforces that query is a free-text search but adds no new parameter-level details. Baseline for full coverage is 3.

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

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

The description clearly states 'Search EBI BioSamples' and specifies the type of metadata and search fields (organism, tissue, keyword). It distinguishes from siblings like 'get_sample' which retrieves a single sample.

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

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

The description mentions 'Free-text search' and 'Keyless', giving usage context. However, it does not explicitly state when not to use this tool or point to alternatives like 'get_sample' for specific sample retrieval.

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 safe, read-only, idempotent behavior. The description adds embedding model (BGE-base-en), similarity (cosine), chunking (500-char windows), character cap (200K chars with truncation flag), and offset verification. No contradictions.

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

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

Four concise, front-loaded sentences covering purpose, usage, technical details, and pairing. No wasted words.

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

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

Given low complexity (3 params, no output schema), the description is fully adequate: it explains what, when, how, technical specifics, and relation to sibling tool. No gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds examples for query, explains the 200K char cap for text, and mentions default limit. This adds some value beyond schema, justifying a 4.

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

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

The description clearly states the tool performs semantic search inside a fetched record, distinguishes it from sibling tools by noting it's for large records and pairs with ask_pipeworx_grounded. It specifies returning top-N passages with offsets and similarity scores, 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?

Explicit guidance: use when the record is too big to fit in the prompt, and pairs with ask_pipeworx_grounded for grounding over passages. No explicit exclusions but clear context of use.

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

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

The description aligns with annotations (write operation, idempotent, non-destructive) and adds behavioral context: requires OAuth, returns subscription id, explains SMS verification and rate limits, webhook signing and auto-disable. No contradictions.

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

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

The description is well-structured and front-loaded with the main action. It is detailed but not overly verbose; however, it could be slightly more concise by merging some type and delivery details. Still, every sentence serves a 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?

The description covers the main action, return value, type-specific details, delivery options, and limitations like SMS cap and webhook auto-disable. No output schema is present, so the return value is explained. It could mention error conditions, but overall complete for a create tool.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond the schema: it explains each type's specific params with examples, details delivery constraints, and elaborates on webhook secret handling. Every parameter is well-documented.

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

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

The description uses a specific verb ('Create') and identifies the resource as 'proactive monitoring subscription to a live-data event stream', clearly distinguishing it from sibling tools like list_subscriptions and unsubscribe. Supported types and delivery channels are enumerated.

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 prerequisites (Pipeworx OAuth account) and provides context for when to use (creating subscriptions). It does not explicitly list when not to use, but sibling tools like list_subscriptions and unsubscribe serve as clear alternatives for other operations.

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. The description adds behavioral details: returns category-bucketed examples with tool/argument shapes, and clarifies that it is safe and idempotent (no side effects). Slight deduction for not explicitly reiterating idempotency, but annotations cover this.

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

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

The description is front-loaded with purpose and usage. It is somewhat lengthy due to listing examples and topics, but every sentence earns its place for an onboarding tool. Could be slightly more structured, but still clear and 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?

With no output schema, the description fully explains what the tool returns (category-bucketed examples with tool/argument shapes). It covers all necessary context: the optional parameter, the use case, and the source (live catalog). Comprehensive for a simple tool.

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

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

Schema coverage is 100% and already describes the topic parameter. The description adds value by providing examples (finance, pharma, betting) and explaining the effect of omission vs. passing a topic, which helps the agent decide how to invoke the tool.

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

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

The description explicitly states that the tool returns category-bucketed example questions with exact tool+argument shapes, and positions it as the onboarding entry point for a new agent. It distinguishes from siblings by advising to use it first when unsure what Pipeworx can do.

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

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

Clear instructions: call with no arguments for full spread or pass a topic to focus. Explicitly states to use it first when onboarding, providing both when-to-use and implied alternatives (e.g., ask_pipeworx after gaining familiarity).

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

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

Beyond annotations (idempotent, non-destructive), the description adds key behaviors: ownership enforcement, row deactivation (not deletion), and that historical events remain available via recent_alerts. No contradictions.

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

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

Two sentences with zero waste. Every word serves a purpose: action, constraint, behavior, and side-effect.

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 one-parameter tool with no output schema, the description covers the action, constraints, and effects completely, including mention of related tool 'recent_alerts' for historical data.

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

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

The schema already fully describes the single parameter 'id' (type, required, description). The description does not add additional parameter context, so baseline 3 is appropriate.

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

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

The description clearly states the action ('Cancel a subscription by id'), specifies the resource (subscription), and distinguishes it from siblings like 'subscribe' and 'list_subscriptions' by mentioning ownership enforcement and deactivation behavior.

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 ownership enforcement ('you can only cancel your own subscriptions'), which guides usage. It does not explicitly list when not to use or alternatives, but the tool's purpose is clear and distinct from siblings.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses crucial behavioral details: the meaning of 'could_not_verify' (check did not happen, not evidence for/against), the distinction between 'unsupported' and other verdicts, and the two verification paths with verbatim evidence. It also mentions the structured vs. grounded pipeline behavior. 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 front-loaded with example queries, then explains the verification paths, return values, and important edge cases. Although lengthy, every sentence adds unique value—there is no fluff. It is well-structured for a complex tool, making it easy to parse.

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

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

For a tool with no output schema, the description fully explains the returned verdicts, the reasoning/evidence, and the critical error semantics (could_not_verify vs unsupported). It also covers the two data paths and the callers' obligations, making it complete for an agent to invoke correctly without needing additional context.

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

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

The input schema provides 100% coverage with detailed descriptions for both 'claim' and 'tolerance_pct', including examples and default behavior. The tool description adds no new parameter-specific information beyond what the schema already states (e.g., tolerance_pct usage is fully described in the schema). Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as a natural-language claim verification tool, providing example queries and explicitly stating its function: 'check whether something a user said is factually correct.' It also distinguishes itself from siblings by noting it replaces a multi-step pipeline (NL parsing, entity resolution, data lookup, comparison) and details the two verification paths (SEC EDGAR/XBRL for company-financial claims, grounded pipeline for all others).

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 also clarifies the fall-through behavior for any factual claim and contrasts it with the alternative of making multiple sequential calls. This gives the agent clear guidance on selection.

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