Biostudies

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description's main behavioral disclosure is the default model (Workers AI Llama-3.3-70b free) and the ability to probe Anthropic with a BYO key. It also notes the return format (per-model and combined view). This adds meaningful context beyond annotations.

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

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

The description is concise (3 sentences) and front-loaded: first sentence defines the core action, second sentence adds key configuration details, third sentence describes the return format and use cases. Every sentence serves a purpose 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?

Given 4 parameters (all documented in schema), no output schema, and annotations covering safety, the description is complete: it explains the return format (per-model score, confidence, etc.), the default model, API key handling, and typical use cases. No critical information is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default model for the 'models' parameter and clarifying that '_apiKey' is only needed for Anthropic and that the user pays Anthropic directly. This extra context improves usability 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 tool probes LLMs for knowledge about an entity and scores visibility (0-100). It specifies the verb 'probe' and the resource 'LLMs for business/brand/product/topic visibility'. Although siblings include similar tools like 'scan_competitor_ai_presence', this description's detailed behavior (per-model scoring, default model, return format) effectively distinguishes 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 provides clear usage context: helpful for AI-marketing audits, pre-launch checks, competitive monitoring. It also explains when to use the _apiKey parameter to enable Anthropic. However, it does not explicitly state when not to use the tool or mention alternatives from the 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?

Annotations say readOnly/openWorld/idempotent, and the description adds exactly the kind of behavior an agent needs to know: it routes to other tools, fills arguments, returns citations, and is non-mutating. Text at the end appears garbled/corrupted but rest states important routing behavior clearly.

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 opening is excellent and front-loaded, but the description is much longer than typical tool descriptions, includes a long categorical list of domains and examples, and ends in visibly corrupted/garbled text that adds noise. It earns its keep for routing guidance but could be tightened.

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 that there is no output schema, the description explains what the tool returns (structured answer with citation URIs). It lists examples and when to use alternatives. Slight gap: it doesn't state that it returns the answer itself rather than a tool invocation, but the citation and routing language implies it.

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

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

Schema gives 100% coverage with six aliases for the same natural-language question field. Description gives pragmatic guidance beyond the schema: use natural language, can include a code like $NVDA for SEC filings, and examples demonstrate proper usage. Slightly redundant alias list, but not a 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?

Description states a clear verb ('routes your question'), specific resource (5,738 tools across 1,499 verified sources), and domain areas. The 'PREFER OVER WEB SEARCH' framing strongly distinguishes it from generic search tools.

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

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

Explicitly says when to prefer it over web search, lists triggering phrases, gives examples, and compares it to sibling alternatives (ask_pipeworx_grounded and deep_research) with selection criteria ('hallucination-resistant', 'multi-part questions'). Better than most tool descriptions.

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

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

Beyond the annotations, the description discloses that this is a beta router with live candidate routing tests, that no candidate is currently active as of a specific date, that results are compared against the stable router, and that it falls back to nothing because it is a fully working router. This is substantial behavioral context that annotations alone cannot provide.

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

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

The description is organized with the beta status, current state, usage instruction, and fallback behavior each in distinct sentences. There is minor redundancy between 'identical universal router' and 'currently matches ask_pipeworx exactly', but every sentence contributes meaningful information.

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

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

For a beta variant of a known sibling tool, the description is complete: it specifies current equivalence, usage intent, evaluation purpose, and the fact that no fallback exists. It also references the same response shape as ask_pipeworx, which is sufficient given the absence of an output schema.

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

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

Schema description coverage is 100%, with all parameters documented as aliases for 'question'. The description says 'same arguments' as ask_pipeworx but adds no semantic detail beyond what the schema already provides; the baseline of 3 applies because the schema carries the burden effectively.

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 this is the beta version of ask_pipeworx: an identical universal router with the same 5,738 tools, arguments, and response shape, but with candidate routing improvements. It clearly distinguishes itself from the stable ask_pipeworx sibling and from ask_pipeworx_grounded by naming the experimental edge.

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

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

The description explicitly says to use it exactly like ask_pipeworx when you want the newest routing, and it explains the current state (no active candidate, so it matches ask_pipeworx exactly). It does not explicitly enumerate exclusions for stable or grounded alternatives, but the guidance is clear enough for an agent to decide when this variant is intended.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavior beyond that: exact success return shape, exact refusal shape, the five refusal reasons, and the fact that evidence is a verbatim quote. It also transparently discloses the extra LLM call cost, which no annotation could convey. No contradiction with the annotations.

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

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

The description is dense but every sentence earns its place: it leads with the core concept, explains the mechanism, specifies return and refusal contracts, gives usage conditions, and names the cheaper alternative. It is front-loaded and free of filler.

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

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

The tool is simple in input but behaviorally rich, and the description covers the full behavioral contract: what it returns, when it refuses, why one would choose it, and when not to. No output schema exists, so the description's explicit return and refusal shapes are especially important and are fully provided.

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

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

Schema description coverage is 100% and the input schema already documents the single meaningful parameter and all five aliases. The description does not add parameter-level detail beyond the schema, but it also does not need to because the schema is complete. 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 names a specific, differentiated behavior: 'Hallucination-resistant answer mode for high-stakes reads' that extracts answers only from tool results. It also distinguishes itself from ask_pipeworx by describing the same routing plus strict evidence-based extraction. This goes well beyond a vague verb and clearly separates it from siblings.

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

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

Explicit guidance is given: use whenever an answer will be quoted, cited, or acted on and the agent must not invent facts, listing concrete domains like financial verdicts and legal claims. It also names the alternative and when to prefer it: 'prefer ask_pipeworx for casual lookups' and notes the extra LLM call cost. This is model-complete routing guidance.

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

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

Beyond annotations (readOnlyHint, openWorldHint, etc.), the description details fan-out behavior, short-circuit conditions (low confidence, closed markets, wide spreads), resolver contract, parent event extractor, and cancellation rule parsing. This provides rich behavioral context.

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

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

The description is long but front-loaded with the core purpose. Every sentence adds value, though it could benefit from bullet points for structure. Nonetheless, it is well-organized and concise for the amount of information conveyed.

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

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

With no output schema, the description thoroughly covers return fields: market details, analysis (model probability, edge, warning), evidence keys, resolver contract, parent event, news fields, safety notes, cancellation rules. It is exceptionally 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%, baseline 3. The description adds meaning: explains 'market' can be slug, URL, or question text; defines 'depth' enum values with defaults; clarifies 'include_raw' usage. This adds value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input types (slug, URL, question text) and output (evidence packet + market-vs-model comparison). This distinguishes it from sibling tools like polymarket_edges or 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?

Explicit usage examples are given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also advises checking result fields before trusting analysis. While it doesn't explicitly state when not to use, the context is clear enough.

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

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

Beyond readOnlyHint, idempotentHint annotations, the description details data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), specific metrics pulled, off-calendar fiscal year handling, and sorted results by primary metric. 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 with information but front-loaded with purpose and example queries. Slightly long but 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?

Despite no output schema, the description explains return format (paired data + citation URIs) and sorting behavior. For a tool with 2 parameters, this is highly 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% with good descriptions. The description adds value by explaining the enum values (type=company/drug) with concrete data examples and handling of fiscal years, enriching beyond schema.

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

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

The description clearly states the tool performs side-by-side comparisons of 2-5 companies or drugs, with example queries. It distinguishes from sibling tools like entity_profile by emphasizing efficiency over sequential lookups.

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

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

Explicit guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' Also mentions it replaces 8-15 sequential lookups, clearly indicating when to use this tool.

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

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

Annotations only carry the safety profile (readOnly, idempotent, non-destructive), so the description carries the full behavioral burden — and it delivers. It discloses the auth/tier gate, the findings-packet shape (verbatim evidence + confidence + source + fetched_at + pipeworx:// citation, gaps[], contradictions[]), the guarantee that citations are always resolvable, the 'never invented' policy, waiting-time expectations (15-60s, up to ~90s for thorough), and hop semantics per depth. No contradiction with annotations; the description refines openWorldHint by clarifying the world is a 1,499-source structured catalog, not the open web.

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

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

The description is long, but the tool is genuinely complex (parallel routing, three depth levels, citation semantics, auth gating) and every sentence carries distinct information. It is well front-loaded — auth requirement and drop-in alternative come first — but it overlaps somewhat with the schema's depth enum descriptions, and some segments could be tightened without losing 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?

With no output schema, the description must stand in for the return contract — and it does, specifying the findings-packet fields, gaps[] and contradictions[] arrays, the hop field, and the citation_uri resolvability guarantee. Combined with the account/tier gating, latency forecast, and explicit fallback routing, nothing an agent needs to decide whether to call this tool, or to interpret its results, is missing.

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

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

Schema coverage is 100%, so the schema already documents both parameters and the depth enum in detail; the baseline is 3. The description adds operational semantics the schema lacks: thorough requires a paid plan, latency per depth band, the practical meaning of gap recovery and lead-chasing, and example questions ('compare X and Y's regulatory + financial exposure'). This is meaningful added value, but the schema already does heavy lifting, so it earns a 4 rather than a 5.

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

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

The description states a specific action with a bounded resource: 'Grounded multi-source research across Pipeworx's 1499 STRUCTURED data sources... in ONE call — this is NOT open-web search.' It explicitly distinguishes itself from open-web search and from the sibling ask_pipeworx, and it gives concrete example questions. The verb+resource+exclusions are all present, so an agent can differentiate this from its 30+ siblings without opening the schema.

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

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

Usage guidance is explicit and bidirectional. The description says 'Best for broad/multi-part questions over structured data' and tells the agent exactly when to use ask_pipeworx instead: single lookups, breaking/colloquial current-news topics, and when the user is not signed in. It even explains the failure mode ('deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog'), so the routing decision is fully specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns top-N relevant tools with names, descriptions, and full input schemas ready to call, and that it is meant to be called first. This provides useful 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 two focused sentences: first states purpose and domain coverage, second gives usage guidance and return value details. No wasted words, front-loaded with essential 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 role as a search/discovery tool with 6 parameters (mostly aliases), no output schema, and clear annotations, the description fully explains what the tool does, when to use it, and what it returns, making it complete for agent understanding.

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 each parameter. The description adds value by explaining that multiple aliases (query, q, task, search, description) are accepted, and provides examples in the schema examples, which clarifies usage.

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

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

The description starts with 'Find tools by describing the data or task' and enumerates specific data domains, clearly stating the tool's purpose as a discovery and search mechanism. It distinguishes from sibling tools by being a meta-tool that returns other tools' schemas.

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

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

The description explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It implies when not to use it (when you already know which tool) but doesn't explicitly state exclusions. Alternatives are the sibling tools, but no direct comparison is made.

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

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

The description adds substantial behavioral context beyond the annotations: parallel fan-out across many sources, source fallback (GDELT→GNews), soft-failure of the USPTO API, and the meaning of empty sections via sources_used/sources_failed. It also explains resolved:false behavior for private companies. This goes well beyond the read-only/idempotent hints already provided.

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

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

The description is dense and front-loaded with purpose and routing guidance. It packs a lot of valuable detail into one continuous block, though a bit more paragraph structuring would improve scannability. Every sentence carries functional information, so there is little waste.

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

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

For a tool with no output schema, the description covers all essential runtime expectations: input formats, resolved-name behavior, per-source return categories, soft-fail semantics, sources_used/sources_failed, and the private-company no-match case. An agent has enough context to call this tool correctly and interpret the response.

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

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

Schema coverage is 100%: both parameters already have detailed descriptions in the input schema. The tool description largely restates the same value shapes (ticker, CIK, company name) rather than adding fundamentally new parameter-level semantics. Some output-context additions like resolved_from/resolved_to are useful but not parameter meaning.

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+resource pattern ('full cross-source profile of a US public company in ONE parallel call') and anchors it with concrete user phrasings. It also distinguishes itself from chaining single-pack lookups, making its purpose unmistakable even among many siblings.

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

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

It explicitly states when to use the tool ('when the user asks for a holistic view') and gives a strong routing directive ('ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups'). It also covers the private-company edge case, telling the agent what result to expect instead of treating it as a generic failure.

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. The description adds context about clearing sensitive data and addressing staleness, which is valuable beyond annotations.

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

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

Two concise sentences with no wasted words. Front-loaded with the core action, followed by usage guidance.

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

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

Given the simple single-parameter interface and rich annotations, the description fully covers what an agent needs: purpose, usage context, and relation to siblings.

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 description does not need to add much. The description does not repeat parameter details; baseline score 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 uses a specific verb 'Delete' and identifies the resource as 'memory by key'. It clearly distinguishes from sibling tools 'remember' and 'recall' by specifying deletion.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also mentions pairing with 'remember' and 'recall', providing 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, openWorldHint, idempotentHint true, and destructiveHint false. The description adds that the tool fetches the page, extracts title/description/key links, and outputs standard llms.txt markdown. This explains the internal process beyond annotations. It does not contradict annotations. Minor omission: no mention of error handling or rate limits.

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: three sentences plus a bullet list of use cases. It is front-loaded with the core purpose, and every sentence adds essential information. 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?

The tool has only two simple parameters, no output schema, and the behavior is straightforward (fetch, extract, format). The description explains the output format and typical use. It is mostly complete; a note about handling failed fetches could be added but is not critical for this tool's simplicity.

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

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

Schema coverage is 100% with clear descriptions for both parameters (url and max_links). The description does not add further semantic meaning to the parameters beyond what the schema provides. The tool's description focuses on purpose and output, not parameter details, 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 purpose: generating a production-ready llms.txt file for any URL. It specifies the verb 'Generate', the resource 'llms.txt file', and the scope 'for any URL'. This distinguishes it from siblings that focus on other tasks like AI visibility checking or research.

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

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

The description includes a 'Useful for' section listing three concrete use cases: indexing a client's site, drafting for own project, or auditing a competitor. This provides good context but does not explicitly state when not to use the tool or mention alternative tools. No sibling tool directly competes with this function, so alternatives are less critical.

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 hints (readOnly, idempotent, etc.). The description adds value by stating it returns specific fields (title, attributes, counts) and that it is keyless, which goes beyond the annotations.

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

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

The description is concise with two sentences that front-load the core purpose. No unnecessary words, and each sentence adds useful information.

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

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

For a simple tool with one required parameter and no output schema, the description covers all necessary context: what it does, input format, and what return fields to expect.

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

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

Schema coverage is 100% with a description for the accession parameter. The description adds an example and clarifies the accession format, enhancing meaning beyond the schema.

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

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

The description clearly states the tool gets metadata for a single EBI BioStudies study by accession, with an example and specific return fields. It distinguishes itself from sibling tools like 'search_studies' by focusing on a single study.

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

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

The description implies when to use (to get metadata for a specific study) but does not explicitly mention when not to use or provide direct alternatives. However, the sibling tool 'search_studies' serves as an alternative for listing studies.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds return fields, scope ('caller's'), and default active behavior. No contradictions.

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

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

Two sentences with no fluff: first states purpose and returns, second gives usage guidance.

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

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

Simple tool with optional param and no output schema; description covers purpose, returns, and usage. Complete for agent invocation.

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

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

One boolean parameter fully described in schema. Description adds value by listing return fields not in output schema.

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

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

Clear verb+resource: 'List the caller's active subscriptions.' Distinguishes from siblings 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?

Explicit when to use: 'review what you're monitoring before adding more or to find an id to cancel.' Implies not for creating or canceling subscriptions.

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 present but all false, offering no behavioral hints. The description compensates richly by disclosing rate limits (5 per identifier per day), the claim_token return mechanism, the fact that it's free and doesn't count against quota, and that the team reads digests daily with roadmap influence. This goes far beyond what annotations provide.

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

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

The description is longer than average but every sentence serves a purpose: purpose, usage, exclusions, token mechanics, rate limits, and incentives. It is front-loaded with the primary action and structured logically. Slight verbosity in the exclusion clauses 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?

Despite having no output schema, the description covers the key return value behavior (claim_token) and the two-mode operation (filing vs. reading a reply). It also addresses rate limits, scope boundaries, and content guidelines. For a 4-parameter tool with a nested context object, the description is complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context for claim_token (how to use it to read replies) and message (advice to describe issues in terms of Pipeworx tools/packs and not paste end-user prompts). This enhances the schema's parameter descriptions.

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

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

The description opens with a specific verb phrase: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' This clearly states the tool's purpose and scope (feedback about Pipeworx tools) and distinguishes it from sibling tools that are research/visibility oriented. The resource and intent are unambiguous.

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

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

Provides explicit when-to-use guidance with enumerated scenarios (bug, feature/data_gap, praise), a clear exclusion (only for tools served by this Pipeworx connection, not other MCP servers), and a concrete alternative action (file with that server instead). Also explains the claim_token workflow for following up, giving complete usage context.

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

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

Annotations already cover safety (readOnly, openWorld, idempotent). Description adds valuable context: data source (CF analytics-engine), no PII, structure (pack, tool, count), caching behavior (5min-1h). No contradictions.

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

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

Three sentences, no wasted words. Front-loaded with purpose, then uses. Clear structure with bullet points for use cases.

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 1 optional param, no output schema, and rich annotations, description covers all needed: what is returned, use cases, data source, privacy, caching. No missing details.

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?

Single parameter 'window' has 100% schema coverage via enum. Description adds semantic guidance: shorter windows for hot trends, longer for steady-state. Default is stated.

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 returns 'top tools, top packs, and total call volume' over a window, with specific verbs and resource. It distinguishes from siblings like discover_tools by focusing on trending data from other agents.

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

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

Explicitly lists three use cases (discovering hot data, confirming canonical tools, aligning use case). While it doesn't state when not to use, the use cases are clear and context implies it's for trend discovery.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: default scan of top 200 markets, semantic anchor (0.30 Jaccard similarity), partition filter (placeholder slugs), and fill check for 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?

The description is comprehensive but somewhat verbose, with multiple sentences covering details that could be streamlined. However, it is well-structured, front-loading the purpose and then explaining modes in order.

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

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

Despite no output schema, the description thoroughly explains return structure (opportunities with fields, partition_check with sum_yes_prices, etc.) and covers edge cases like fill check and placeholder filtering. Refers to companion tool for custom sizing.

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

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

Schema descriptions for both parameters exist (100% coverage). The description goes further by explaining behavior for each parameter: event mode walks child markets and performs checks, topic mode searches across events. Adds examples and clarifies expected input types.

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

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

The description starts with a clear verb-resource pair ('Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks') and distinguishes three modes (no args, event, topic). It clearly differentiates from sibling tools like polymarket_edges, polymarket_edge_tracker, and polymarket_fill_risk.

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

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

Provides explicit guidance on when to use each invocation mode: no args for trending scan, event for single-market analysis (recommended), topic for cross-event scanning. Explains cross-event mode catches patterns single-event misses, but lacks explicit when-not or alternative tool references.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds rich behavioral context: caching at KV level keyed on knobs, three model families with detailed methodology, response segmentation with diagnostics, and 24h move warning. 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 thorough but lengthy, with multiple paragraphs and detailed technical exposition. While well-organized with bold terms and sections, it could be more concise for quick scanning. Every sentence is informative, but the density may be overwhelming.

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

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

Despite no output schema, the description fully explains response structure (by_segment with three segment types), edge_pp_net, kelly fractions, liquidity/spread/volume, and diagnostic counters. Caching behavior, parameter knobs, and model details are all covered, making the tool self-contained 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining parameter intent (e.g., 'Tradeable-edge knobs' group), providing usage context for min_liquidity, max_spread_pp, and min_partition_leg_kelly, and clarifying how parameters interact with edge calculation and filtering logic.

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

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

The description starts with a clear verb+resource: 'Scan top Polymarkets markets and return opportunities where Pipeworx data disagrees with market price.' It explicitly targets 'what should I bet on today' use case and distinguishes from siblings like polymarket_arbitrage by focusing on model-driven edge detection.

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

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

Provides explicit use case: 'Built for "what should I bet on today" – agents discover opportunities without paging hundreds of markets.' It also notes limitations (Fed bets unreliable with free data, cached 1h). However, it does not explicitly contrast with sibling tools like bet_research or compare_entities.

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 behavior. Description adds critical behavioral details: data source (daily snapshots), response structure (tracked, expired, snapshot_dates), decay computation, and limitations (60-day TTL, snapshot start). No contradictions with annotations.

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

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

The description is dense but well-structured: purpose first, then args, then response format, then limitations. Every sentence conveys necessary information given the tool's complexity. Could be slightly more concise, but no waste.

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

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

Without output schema, the description fully documents return values (tracked, expired, snapshot_dates with field explanations). Also covers limitations, making it self-contained for an agent to use correctly.

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

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

Schema covers both parameters fully (100% coverage). Description adds context: clarifies 'days default 14 max 30' (schema says clamp 2-30), and explains 'window' as snapshot family. This adds value beyond the schema.

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

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

The description uses specific verbs ('edge persistence and decay telemetry') and clearly states the resource (daily polymarket_edges snapshots). It answers a concrete question and distinguishes from the sibling tool 'polymarket_edges' by focusing on persistence and trends.

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 answers when to use: to check edge persistence and decay. Describes the trade context (fresh vs old edge). Lacks explicit 'when not to use' statements, but context implies 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 mark it as read-only and idempotent. The description adds behavioral details: it walks the order-book ladder, computes slippage, fillability, and returns a verdict. It also warns about partial basket fills converting arb into unhedged directional positions.

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

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

Though lengthy, every sentence is necessary. Uses CAPS for emphasis on modes and key warnings. Front-loaded with purpose and requirements, then detailed mode-specific explanations.

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 enumerates all returned fields for both modes (top_of_book, vwap_fill_price, slippage_pp, etc.). Covers edge cases like thin legs and forced directional risk. Comprehensive given complexity.

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

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

Schema coverage is 100% with descriptions. The description adds meaning: explains default side behavior in both modes, and the dual interpretation of size_usd ('USD to spend on buys, target proceeds on sells; basket mode: settlement notional'). This goes beyond the schema.

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

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

The description clearly states it is a 'Realizable-vs-theoretical edge check against live CLOB order-book depth,' distinguishing between single-market and basket modes. It is distinct from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', providing clear context 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 mark this as read-only, idempotent, and non-destructive, so the description adds substantial behavioral context beyond those hints. It discloses that compatibility_warning and compatibility_codes can be non-empty even when matches exist, that pairing is always unverified, that temporal_alignment null means 'could not compute' rather than aligned, that Kalshi fees are not modeled, and that spreads are gross not net — far more than annotations supply.

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

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

The description is long, but the tool is complex and lacks an output schema, so nearly every clause carries necessary information about modes, safety fields, flags, skipped legs, and fee disclosures. It is front-loaded with the core purpose and organizes distinct concerns with clear markers like 'TWO MODES', 'RESPONSE', and 'SAFETY FIELDS'; still, it reads as a dense wall of text and could benefit from formatting into sections.

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?

Because there is no output schema, the description carries the full burden of explaining the return shape, and it does so thoroughly: leg-by-leg prices, top_spreads_pp, per-entry flags, skipped_unclassified, low_confidence_pairs, temporal_alignment, fees_note, and skipped counters. It also covers crucial edge cases like null temporal alignment, non-empty warnings despite positive matches, and the unverified nature of every pairing — leaving little ambiguity 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%, giving the baseline of 3, but the description adds meaningful behavioral semantics beyond the schema. It explains that one mode uses pre-mapped shortcuts while the other takes explicit tickers/slugs, that both modes run the identical overlap matcher, and that explicit values override topic-mapped sides — context that helps an agent choose parameter combinations correctly.

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

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

The description opens with a specific verb ('Cross-venue spread between Kalshi and Polymarket for the same resolving question') and clearly identifies the resource. It differentiates itself from likely sibling tools by naming its two operating modes and what it returns, so an agent can tell it apart from related market-analysis tools.

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

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

The description gives clear usage context: when bet shapes are equivalent the spread is a signal, when they are not the tool flags it, and both pre-mapped and explicit modes run the same matcher. It does not explicitly name an alternative tool to use instead, but the caveat that most pre-mapped topics return compatibility_warning and that pre-mapped is not tradeable gives practical guidance about when to distrust results.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds scoping details (anonymous IP, BYO key hash, account ID) and clarifies the behavior of omitting the key argument, which provides 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 three sentences: first defines the core action, second explains when to use it, third adds scoping and sibling references. 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?

For a simple read-only tool with clear annotations and schema, the description covers all essential aspects: purpose, usage context, parameter behavior, scoping, and relationship to siblings. No gaps 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 describes the single optional 'key' parameter with coverage 100%. The description restates that omitting the key lists all keys, which adds minimal new meaning beyond what the schema provides.

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

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

The description clearly states the tool's verb ('retrieve'), resource ('a value previously saved via remember'), and behavior when key is omitted ('list all saved keys'). It distinguishes itself from siblings by explicitly mentioning 'remember' and 'forget' as counterparts.

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

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

The description provides explicit when-to-use guidance ('look up context the agent stored earlier... without re-deriving it from scratch') and alternative tools ('Pair with remember to save, forget to delete'). It also specifies scoping ('Scoped to your identifier').

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 claims that setting mark_read:true flags events as read, which implies a state change. However, the annotations include readOnlyHint:true, which indicates the tool does not modify state. This contradiction means the description misrepresents the tool's behavior, severely impacting transparency.

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, front-loaded with the main purpose, then provides parameter details, behavior disclosure, and an alternative endpoint. Every sentence adds value, no fluff.

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

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

Given the tool has five parameters, no output schema, and annotations covering safety, the description fully explains return fields (source, citation_uri, payload), filtering options, the effect of mark_read, polling support, and even an alternative URL. It leaves no major gap for an agent to use the tool correctly.

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

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

Schema coverage is 100%, and the description adds meaningful context for key parameters: explains 'type' with an example ('sec_8k'), specifies 'since' as ISO timestamp, and clarifies that 'mark_read' causes returned events to be flagged as read so subsequent calls only show newer ones. This goes well beyond the schema's basic descriptions.

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

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

The description clearly states the verb 'Pull fired events' and identifies the resource as 'your subscription feed'. It distinguishes itself from sibling tools by specifying 'recent alerts from the evaluator', which is not covered by other tools like list_subscriptions or 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 explains when to filter by type and/or ISO timestamp, and how mark_read controls read state for subsequent calls. It also notes that polling works fine and provides an alternative endpoint for scripts/dashboards. However, it does not explicitly state when not to use this tool or directly compare to siblings.

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

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

Discloses parallel calls to multiple sources, fallback from GDELT to GNews, and soft-fail for patents post-May 2025. Annotations already provide readOnly, idempotent hints; description adds valuable behavioral context 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?

Description is long but well-organized: example queries first, then operational details, parameter notes, return format, and alternative tool. Every sentence is informative, though slightly verbose.

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

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

No output schema, but description sufficiently explains return value structure (changes[] grouped by source, total_changes, citation URIs). All parameters are covered, and potential failures are noted.

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% (3 params all described), but description adds significant value: explains `since` relative shorthand, provides examples, clarifies `type` is limited to 'company', and notes `value` accepts ticker or CIK. More than 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 provides a change feed for a company over a time window, including SEC filings, news, and patents. It uses example queries to convey purpose and distinguishes itself from entity_profile.

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

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

Explicitly tells when to use (for recent changes, news, updates) and when to use alternative (entity_profile for static profile). Also provides guidance on the `since` parameter format and notes fallback behavior.

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

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

Annotations provide readOnlyHint, destructiveHint, and idempotentHint. Description adds key behavioral details: scope by identifier, persistence (24h for anonymous, persistent for authenticated), and pairing with recall/forget. No contradictions.

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

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

Three sentences, front-loaded with purpose, no redundant words. Every sentence adds value.

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

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

For a simple write tool with two required parameters and no output schema, the description provides enough context about scope, persistence, and related tools to enable correct usage.

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

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

Schema covers 100% of parameters with descriptions. The description adds value by providing concrete key examples (e.g., 'subject_property', 'target_ticker'), enhancing understanding beyond schema.

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

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

Clearly states the action ('save data') and resource ('key-value pair'), and distinguishes from sibling tools like recall and forget by specifying the purpose of carrying forward information.

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

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

Provides explicit guidance on when to use ('discover something worth carrying forward'), why ('so you don't have to look it up again'), and pairs with related tools (recall, forget).

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

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

Annotations already convey read-only, idempotent, open-world, and non-destructive, but the description adds substantial new behavioral context: graceful degradation ('if GLEIF or OpenFIGI is unavailable, the EDGAR identifiers still return'), ambiguity handling (asserts nothing and returns figi_candidates), explicit unresolved reporting, source labeling of every identifier, and internal cascading lookups. 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 well front-loaded with example queries and the core purpose, but the company-type explanation is a single sprawling parenthetical packing several behaviors (FIGI matching, ambiguity, ISIN mapping, degradation) into one dense block. It is thorough and nearly every sentence earns its place, but the wall-of-text structure hurts agent scannability.

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

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

For a complex two-type tool with no output schema, the description explains return identifiers (CIK, ticker, LEI, FIGI, RxCUI), data sources, ambiguity outcomes, and failure modes. The main gap is a clean statement of the response object's shape; mentions of figi_candidates and unresolved partially cover this but a structured return description would make it fully complete.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds critical value-param semantics: the 'ENTITY NAME ONLY' rule with a concrete bond example ('NEW YORK ST DORM AUTH' vs trailing security-class words matching nothing) and the accepted input forms (ticker, CIK, ISIN, name). The type param is also enriched by explaining exactly what each type returns.

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 concrete example queries ('What's the ticker for…', 'find the CIK for…') and states the core function: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' This is a specific verb+resource that also distinguishes it from siblings like entity_profile and compare_entities by positioning it as the identity-resolution prerequisite.

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?

'Use FIRST whenever you have a name but need an ID' is an explicit trigger condition, reinforced by the example-query list and the efficiency note that it 'replaces 2-3 manual lookups.' It does not explicitly name alternatives or state when-not-to-use cases, 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it 'probes each entity with ai_visibility_check' and returns a ranked list. However, it does not disclose the multiple API calls, potential latency, or cost implications. Adequate but not rich.

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: first states the core action and output, second gives a concrete use case and lists returned fields. Every word earns its place; no fluff. Front-loaded with the main 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?

No output schema exists, so the description covers the return format (ranked list with score, confidence, signal density). It explains the internal mechanism briefly (probes with ai_visibility_check) and the first-entity treatment. It does not specify error handling or edge cases, but for most agents it's sufficient.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining that the first entity is the 'subject' for narrative and that 'workers-ai' is free default while 'anthropic' requires an API key. This enriches the user's understanding beyond the schema.

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

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

Description uses specific verb+resource: 'Compare AI visibility across multiple entities side-by-side'. It clearly distinguishes from its likely sibling `ai_visibility_check` (single entity) by focusing on comparison and ranking. The phrase 'most/least recognized' adds clarity.

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

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

Explicitly states use case: 'competitive AI-marketing audits' with an illustrative question. Implies when to use (comparison, not single check) but does not explicitly exclude alternatives or mention when not to use. Clear enough for an AI agent.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: partial failures degrade gracefully, bundlephobia's first measurement may take 5-30 seconds, and sources_failed field lists timeouts. 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 comprehensive but not excessively wordy. It front-loads the core purpose and uses concise bullet-like formatting for the return fields. A slightly tighter structure could improve scannability, but it remains 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?

Despite lacking an output schema, the description fully enumerates the return fields (summary block, per-advisory, links, alternative versions) and explains partial failure behavior. Given the tool's complexity and lack of output schema, this is complete and leaves no critical gaps.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds minimal extra semantics beyond noting that scoped packages are accepted and version defaults to latest. Since schema already provides adequate meaning, baseline 3 is appropriate.

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

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

The description clearly states it's a composite check for assessing whether to add an npm package, covering license, advisories, version history, and bundle size. It succinctly defines the tool's purpose and differentiates it from other tools in the sibling list, none of which are dependency scanners.

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

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

Explicitly tells when to use: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also clarifies ecosystem scope (NPM v1) and points users to deps.dev:version for other package managers, providing clear guidance 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?

Description adds behavioral context beyond annotations: 'keyless database' implies no authentication needed, 'links across EBI archives' clarifies scope, and it lists returned fields. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so description complements them.

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

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

Two sentences, front-loaded with core purpose and additional details. No redundant phrases; 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?

Without an output schema, the description adequately explains return fields (accession, title, etc.). It could mention pagination defaults or results format, but schema covers pagination params. Overall sufficient for a search tool with strong annotations.

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

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

Schema coverage is 100% with all three parameters described. The description adds no additional parameter semantics beyond what the schema provides (e.g., 'keyword' for query). Baseline 3 is appropriate.

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

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

Description clearly states verb 'Search' and resource 'EBI BioStudies database', specifies linking across archives, and lists returned fields. Distinguishes from siblings like 'get_study' which retrieves a single study.

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

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

The description implies usage context (searching biological studies via keyword) but does not explicitly state when to use this tool over alternatives or exclude scenarios. No mention of when-not-to-use or comparison with sibling search tools.

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

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

Adds significant behavioral details beyond annotations: returns character offsets, similarity scores, embedding model, window size, truncation cap. 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?

Single paragraph, front-loaded with purpose, every sentence adds value without redundancy.

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

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

Comprehensively covers return values (passages with offsets, scores), truncation behavior, pairing with other tools, and underlying model details—fully compensates for lack of output schema.

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

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

Schema coverage is 100%, and description adds value by providing concrete examples, limits, and defaults (e.g., text ~200K chars, limit 1-20 default 5, query examples).

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

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

Description clearly states 'Semantic search INSIDE a fetched record' and provides specific use cases, distinguishing it from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and gives pairing guidance, but lacks explicit 'when not to use' statements.

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 readOnlyHint=false and idempotentHint=true. The description adds behavioral details: it creates a write operation, returns an id, requires authentication, and imposes rate limits (10 SMS/day). It does not contradict annotations. The description provides context about OAuth requirements and delivery channel constraints that go beyond the annotations.

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

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

The description is relatively long but well-structured. It starts with the core purpose, then lists requirements, supported types with examples, and delivery channels. It front-loads essential information. Minor redundancy in delivery descriptions could be trimmed, but overall it is efficient for 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 complexity of multi-type subscriptions and 3 parameters with nested objects, the description covers all key aspects: subscription types, parameter examples, delivery options, authentication requirements, and rate limits. The lack of output schema is mitigated by stating the return of a subscription id. Missing details like error handling are acceptable.

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

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

Schema coverage is 100%, but the description adds significant value by providing concrete examples for each subscription type in the params object (e.g., sec_8k items, polymarket_edge topic) and detailing delivery options with constraints like phone verification and SMS cap. This context helps in correctly constructing parameters.

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 creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. It distinguishes itself from sibling tools like list_subscriptions and unsubscribe by focusing on creation. The verb 'create' and resource 'subscription' are specific and unambiguous.

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

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

The description explicitly requires a Pipeworx OAuth account, noting that anonymous and BYO users cannot persist subscriptions. It also explains when to use different subscription types and delivery channels. However, it does not explicitly state when not to use this tool or provide direct alternatives beyond the 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 explains that calling returns category-bucketed example questions drawn from a live catalog, aligning with annotations like readOnlyHint (safe read) and openWorldHint (varied responses). It adds context about output structure without contradicting annotations.

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

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

The description is fairly long but well-structured, front-loading example user queries and explaining the output format. While every sentence adds value, it could be slightly more concise without losing clarity.

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

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

For an onboarding tool with one optional parameter and no output schema, the description fully covers purpose, usage, parameter semantics, and return format. It provides all necessary context for an agent to understand and invoke the tool correctly.

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

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

The schema has one optional parameter (topic) with a description. The tool description adds specific examples of topics (e.g., 'finance', 'pharma') and explains behavior when omitted, going beyond the schema to clarify parameter usage.

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

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

The description clearly states that this tool is the onboarding entry point for understanding what Pipeworx can do, returning category-bucketed example questions with tool and argument shapes. It distinguishes itself from siblings like ask_pipeworx by being the first tool to use when unsure of capabilities.

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 instructs to use this tool first when the agent does not know Pipeworx's capabilities, and provides guidance on optional topic filtering versus calling without arguments for a full spread. It mentions meta-tools to learn how to call them, giving clear when-to-use context.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds that the row is deactivated (not deleted) and ownership is enforced. This significantly clarifies the tool's 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?

Three concise sentences with no redundant information. Front-loaded with the main action, then key constraints and side effects.

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 clear annotations, the description covers all essential aspects: action, constraints, effect, and relation to other tools (recent_alerts).

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 'id' is described in the schema as 'Subscription id (uuid) returned by subscribe.' The tool description reinforces this by referencing subscribe, which adds value but the schema already covers the meaning.

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

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

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

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

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

It explains ownership enforcement ('you can only cancel your own subscriptions') and the effect (deactivation, not deletion) with a pointer to recent_alerts for historical events. While no explicit when-not-to-use, it provides clear context.

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

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

The description provides crucial behavioral context beyond annotations: explains the two pipeline paths (SEC EDGAR fast path vs. grounded pipeline), defines all six verdicts, and especially clarifies that 'could_not_verify' means the check did not happen and carries an error—warning callers not to treat it as evidence. This is exactly the kind of nuance an agent needs and goes far beyond the readOnly/openWorld/idempotent hints.

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

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

The description is lengthy but information-dense, front-loaded with trigger phrases and a clear logical structure. Every sentence contributes useful detail (routing, verdicts, caveat, value prop). It could arguably be tightened, but it earns its 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 the complexity of this tool—multiple pipeline paths, a nuanced verdict set, and an important caller-facing caveat—the description covers all essential aspects: what it returns, the meaning of each verdict, how it handles unsupported vs. failed checks, and its advantage over sequential calls. No output schema exists, so the description bears full responsibility for return-value transparency, and it meets that need.

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

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

Schema description coverage is 100%, with both parameters (claim and tolerance_pct) already having detailed descriptions. The tool description adds context about the overall verification behavior but does not add new parameter-specific meaning beyond the schema. Baseline of 3 is appropriate when the schema carries the semantic load.

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

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

The description clearly states a specific verb ('validate', 'verify') and resource ('natural-language factual claims') and differentiates itself from sibling tools by detailing the verification workflow, the two-path routing for financial vs. other claims, and the verdict types returned. This is far beyond a generic statement of 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?

Explicitly states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also describes the internal routing for different claim types, which helps select it over alternatives. However, it does not explicitly mention when NOT to use it or name alternatives like deep_research or ask_pipeworx for general Q&A, so it lacks full exclusion guidance.

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