Hash

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds: costs (free default, BYO key for Anthropic), output structure (per-model {score, confidence, signals, raw_response} + combined view). No contradiction.

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

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

Three sentences front-loaded with main action, then details, then use cases. No fluff, every sentence earns its place.

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

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

Covers purpose, parameters, output, use cases, and cost. Lacks mention of error handling or full output format, but annotations fill some gaps. Good for a tool with no 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%. Description adds contextual meaning: entity is the thing to ask about, models are probe targets, _apiKey is for Anthropic, context disambiguates. Goes beyond schema descriptions.

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

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

Clearly states verb 'probe' and resource 'LLMs for knowledge about entity', specifies scoring visibility 0-100 per model, and distinguishes from sibling tools (e.g., ask_pipeworx, deep_research) by focusing on brand/topic visibility.

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 mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. Provides guidance on default model and API key requirement. Could be improved by mentioning alternatives among siblings.

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

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

Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral context beyond this: it routes to many internal tools, returns structured answers with stable pipeworx:// citation URIs, works on every tier, and is a single fast call. It does not contradict the annotations and discloses the tool's routing behavior and output nature, though it doesn't mention rate limits or failure modes.

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

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

The description is long but structured and purposeful: it leads with the key directive, then lists covered domains, examples, and alternatives. Every sentence contributes useful information, but the list of example queries is somewhat redundant and could be trimmed without losing meaning. Front-loaded and well-organized, but slightly over-stuffed.

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

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

For a complex routing tool with no output schema, the description is highly complete. It explains what the tool does, when to use it, how it routes, what it returns (structured answers with citations), and when to step up to alternatives. It also notes it works on every tier and is the default entry point, covering the operational context. This leaves very little to be desired.

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

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

The input schema has 100% description coverage: all 6 parameters are documented as aliases for 'question'. The description itself does not add parameter-specific semantics beyond what the schema already states, but the schema is self-explanatory. The examples in the description illustrate the parameter usage, but that's marginal added value. 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 that the tool routes questions to the right tool from 5,529 tools across 1,455 verified sources and returns structured answers with citation URIs. It also distinguishes itself from siblings by explicitly comparing to ask_pipeworx_grounded and deep_research, making its unique role as the default entry point 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 gives explicit usage guidance: 'PREFER OVER WEB SEARCH' and lists specific domains (SEC filings, FDA data, etc.). It also provides when-not-to-use direction by saying 'Step up only when needed' and names alternatives (ask_pipeworx_grounded, deep_research), plus examples of appropriate queries. This fully covers when to use and when to choose another 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?

Beyond the readOnly/idempotent annotations, it reveals the beta nature, that no candidate is currently active (so it matches ask_pipeworx exactly), and that it's a full working router with no fallback. It also references the same response shape. This adds meaningful experimental/state context 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 three sentences, each carrying useful information: beta status, current state, and usage guidance. It's somewhat repetitive ('exactly' appears twice) but remains well-structured and front-loaded with the core purpose.

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

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

Provides enough context for this simple router tool: it explains the relationship to ask_pipeworx, the experimental state, and the lack of fallback. Since there's no output schema, the mention of 'same response shape' helps. It's complete for selection and invocation.

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

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

The schema has 100% coverage with descriptions for all six parameters, all aliases for 'question'. The description adds no parameter-specific details, but the schema fully documents them, so the 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 identifies it as a beta universal router with the same 5,529 tools as ask_pipeworx and an experimental routing edge. It explicitly says 'identical universal router' and differentiates from the stable sibling, making purpose and scope unambiguous.

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

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

Explicitly states 'Use it exactly like ask_pipeworx when you want the newest routing' and notes results are compared against the stable router. This gives a clear usage context and implies the stable alternative, though it doesn't explicitly say 'when not to use' or which option to prefer for production stability.

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 substantial behavioral context: it returns structured refusal reasons (not_in_source, no_tool_match, etc.), discloses the extra LLM call cost, and explains that answers are extracted ONLY from tool results. 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 front-loaded with the core purpose, then flows through routing, return shape, refusal behavior, use cases, and cost trade-off. Every sentence adds distinct value; despite length, it is dense and well-structured with clear separation of concepts.

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

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

The tool has no output schema, yet the description fully specifies the success return structure and all refusal reasons, explains the routing mechanism, and compares cost to the sibling tool. This makes it complete for an agent to decide when and how to invoke it, even in high-stakes contexts.

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% because all six parameters are aliases for a single natural-language 'question' field. The description does not add parameter-specific detail, but the schema fully documents the parameters. Baseline 3 is appropriate since the schema carries the burden.

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

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

The description clearly states the tool is a 'hallucination-resistant answer mode for high-stakes reads' and explicitly contrasts it with 'ask_pipeworx' by noting it EXTRACTS answers only from tool results. This gives a specific verb+resource+scope and distinguishes it from its sibling tool.

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

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

It explicitly says 'Use whenever an answer will be quoted, cited, or acted on' and provides exclusions: 'prefer ask_pipeworx for casual lookups.' It also lists concrete high-stakes examples (financial verdicts, legal claims, medical lookups), giving clear when-to-use vs alternative guidance.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds extensive behavioral details: resolver contract, parent event extraction, news fields, safety short-circuits, closed market handling, wide spread warnings, and resolution-rule risk. All these details go well beyond the annotations and provide comprehensive 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 very long, containing many details that could be structured more concisely. However, it uses capitalized headers (CLASSIFIERS, FAN-OUT EXAMPLES, etc.) to organize content. The first sentence clearly states the purpose, but the overall verbosity detracts from conciseness.

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

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

Given the tool's complexity and absence of an output schema, the description is remarkably complete. It covers input formats, processing steps, classifier examples, fan-out examples, response shapes, resolver contract, parent event extraction, safety mechanisms, and resolution-rule risk. Every aspect likely needed by an agent is addressed.

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

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

Input schema covers 3 parameters with 100% description coverage. The description adds value by explaining the depth enum values (quick vs thorough) and the include_raw parameter (when to use true/false). This is 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 researches a Polymarket bet by pulling Pipeworx data. It specifies inputs (slug, URL, question) and outputs (evidence packet, comparison). However, it does not explicitly differentiate from sibling tools like polymarket_edges or polymarket_arbitrage, so it loses a point for lack of sibling distinction.

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 phrases are given: 'Use for should I bet on X, what does the data say about Y, or is there edge in Z.' It also provides detailed fan-out examples per category. However, it lacks guidance on when NOT to use the tool or alternatives, which is a gap given many sibling tools.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it pulls latest financial data from SEC EDGAR/XBRL for companies (with off-calendar year handling) and FAERS data for drugs, sorts results by primary metric, and returns citation URIs. 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?

Every sentence in the description serves a purpose. It starts with intuitive query examples, then states the core functionality, gives a usage preference, details each type's output, explains sorting and output format, and ends with efficiency claim. No fluff; information is front-loaded.

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

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

Given the tool's moderate complexity (two simple parameters, no output schema), the description is complete. It covers input meaning, output format (paired data + citations), sorting behavior, and data sources. For a comparison tool with clear annotations, nothing essential is missing.

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

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

The input schema already provides good descriptions for both parameters (100% coverage). The description adds further meaning by detailing what each 'type' retrieves (company financials vs. drug counts) and providing examples for 'values' per type. This goes beyond the schema, justifying a score above baseline.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs. It uses specific verbs like 'compare' and lists concrete query examples. It distinguishes from sibling tools by explicitly preferring this over sequential single-entity 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?

The description provides explicit when-to-use guidance with example queries (e.g., 'Compare X and Y', 'which is bigger'). It also states 'ALWAYS PREFER over sequential single-pack lookups', effectively excluding use cases where the agent should not use it (i.e., for single entity queries). No misleading guidance.

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

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

Annotations declare readOnlyHint/openWorldHint/idempotentHint, but the description adds substantial behavioral context beyond that: return packet structure (verbatim evidence, confidence, source, fetched_at, gaps[], contradictions[]), the guarantee of never inventing answers, citation_uri fetchability guarantees, semantic excerpting behavior, depth-specific hop/iteration behavior, expected latency (15-60s, thorough ~90s), and account/paid-tier requirements. No contradiction with annotations; it enriches them heavily.

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 and dense, but every clause adds value for a complex tool with explicit alternatives, depth semantics, output format, access requirements, and performance expectations. It is front-loaded with the account requirement and sibling alternative, then proceeds logically. While it could be tightened in spots (e.g., some parentheticals), it remains well-structured and appropriately detailed for the tool's complexity.

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

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

This tool has no output schema, so the description must explain return values itself—and it does thoroughly: findings packet, gaps[], contradictions[], hop field, citation_uri with fetchability guarantee, and semantic excerpting. It also covers access tiers, timing, and depth options. For a tool with this complexity, the description is complete enough for an agent to select, invoke, and interpret results correctly.

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

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

Schema coverage is 100% for both parameters, and the schema already provides enum values and descriptions. The description goes further: it maps depth values to facet counts (quick=3, standard=5, thorough=8), explains the gap-recovery and contradiction-scan behavior per depth, and clarifies that broad/multi-part questions are acceptable ('decomposition is the point'). This adds meaning beyond the schema's basic definitions.

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+resource+scope: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' in ONE call. It explicitly distinguishes itself from open-web search and from siblings: 'this is NOT open-web search', 'For a single lookup use ask_pipeworx', 'For BREAKING... prefer ask_pipeworx'. This is a specific, unambiguous purpose that differentiates it from all siblings.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: 'Best for broad/multi-part questions over structured data', 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'. It also provides an alternative based on account status: 'If you are not signed in, use ask_pipeworx instead'. This fully covers usage context and exclusions.

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, destructiveHint=false, idempotentHint=true. The description adds that the tool returns top-N relevant tools with full schemas and examples, ready to call directly—useful behavioral context beyond annotations. No contradictions.

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

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

The description is concise and well-structured: it opens with the main purpose, then lists domains, then return details, then usage advice. Every sentence is informative 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?

No output schema exists, but the description explains the return format (top-N tools with names, descriptions, and schemas). It covers purpose, usage, and output well. Minor omission: no mention of prerequisites or rate limits, but annotations cover safety.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that query accepts aliases (q, task, description, search) and provides examples in the schema. This clarifies parameter usage 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's purpose: 'Find tools by describing the data or task.' It provides specific examples of data domains (SEC filings, financials, etc.) and explains the return value (top-N tools with schemas). This distinguishes it from sibling tools, which are specific data 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 explicitly advises when to use: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It implies not to use when you already know the tool. Could be more explicit about alternatives, but it's clear enough.

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

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

Annotations already indicate safe, read-only, idempotent behavior. The description adds detailed behavioral context: fans out across multiple sources, lists returned fields, mentions USPTO API sunset and fallback logic. No contradictions.

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

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

The description is packed with useful information in a single paragraph. It's front-loaded with example queries and clear purpose. Could benefit from minor structuring, but no wasted sentences.

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

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

Given the tool's complexity (multiple sources, fallbacks, no output schema), the description covers all key aspects: supported sources, returned fields, known limitations (patent soft-fail), and input constraints.

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 clarifying valid values (ticker or zero-padded CIK), giving examples, and explicitly stating that names are not supported.

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

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

The description clearly states the tool returns a 'full cross-source profile of a US public company in ONE parallel call' and distinguishes from siblings by advising 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' for holistic views.

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 (holistic view), when not to use (names not supported), and provides alternative (use resolve_entity first). This is comprehensive guidance.

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

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

Annotations already indicate destructiveHint=true, and description confirms destructive nature (delete). Adds context about clearing sensitive data and stale context, providing extra behavioral insight beyond annotations.

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

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

Three short sentences with no fluff, efficiently conveying purpose, usage, and sibling tools.

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 full annotation coverage, the description adequately covers purpose, usage, and context, leaving no gaps.

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

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

Schema covers the single parameter 'key' with description 'Memory key to delete' (100% coverage). Description only reiterates 'by key' without adding new detail, so baseline score applies.

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

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

Description clearly states 'Delete a previously stored memory by key.' with specific verb, resource, and method, distinguishing it from siblings like remember and recall.

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

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

Explicitly states when to use (stale context, task done, clear sensitive data) and mentions pairing with remember and recall, providing clear guidance on alternatives.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds process details (fetches page, extracts title/description/key links) that are consistent with these hints and provide extra behavioral context, meeting the bar for transparency with annotations present.

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 no wasted words. It front-loads the main purpose, explains the process in one sentence, and lists use cases in a clear bullet-point style. Every sentence earns its place.

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

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

For a simple read-only tool with no output schema, the description adequately explains the output format ('single text blob ready to drop at site-root/llms.txt') and the extraction logic. It covers the essential completeness needed without being overly verbose.

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

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

Schema description coverage is 100%, with both parameters ('url' and 'max_links') fully described in the schema. The description does not add additional meaning or constraints beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool generates an llms.txt file for any URL for AI crawlers. The title and description align, and it distinguishes itself from sibling tools like 'deep_research' or 'scan_competitor_ai_presence' by specifying a unique output format and use case.

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

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

The description lists three specific use cases (client site indexing, own project drafting, competitor auditing). While it does not explicitly state when not to use the tool or name alternatives, the context signals show no directly overlapping siblings, making the guidance adequate.

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

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

Beyond annotations (readOnly, idempotent), the description adds critical context: input is not stored/transmitted, offline operation, and legacy algorithm risks. 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: first states purpose and algorithm options, second adds behavioral context and legacy warnings. No unnecessary words.

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

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

Given simple tool with comprehensive schema and annotations, the description fully covers purpose, behavior, and usage context. Output schema is unnecessary for a hash function.

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

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

Schema coverage is 100% and already describes parameters. The description adds only default algorithm and algorithm groupings, which is marginal over schema information.

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

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

The description clearly states the tool computes a cryptographic hash (hex digest) and lists supported algorithms. It distinguishes from sibling 'hmac' by emphasizing keyless/offline operation.

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 indicates when to use the tool (keyless/offline hashing) and warns about legacy algorithms for security. It implicitly contrasts with HMAC but does not explicitly list when not to use or 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?

Annontations already indicate readOnlyHint and idempotentHint. The description adds useful context about being offline and keyless, which complements the annotations without contradiction.

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

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

Two concise sentences with no extraneous content. The main purpose is front-loaded, and every word 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 3-parameter tool with no output schema, the description effectively conveys purpose, algorithms, and online/offline behavior. Output format ('hex') is implied, making it sufficiently 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% and descriptions are already clear. The description repeats some schema info (algorithms) and adds 'keyless/offline' context that aids overall understanding but does not significantly enhance parameter meaning beyond what schema provides.

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

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

Clearly states the verb 'Compute', the resource 'HMAC (hex) of text with a secret key', and enumerates supported algorithms. Distinguishes itself from the sibling 'hash' tool by requiring a key.

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?

Mentions 'Keyless/offline' implying no network dependency, but does not explicitly state when to use this versus alternatives like the 'hash' tool or provide exclusion criteria.

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

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

Annotations already declare readOnly and idempotent. Description adds value by specifying returned fields and default behavior (active only). 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 concise sentences, no wasted words, purpose front-loaded.

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

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

One optional param, no output schema but fields listed, annotations present. Fully adequate for this simple listing tool.

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

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

Schema coverage is 100%, so baseline 3. Description hints at include_inactive effect but doesn't add major new nuance beyond schema.

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

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

Description clearly states 'List the caller's active subscriptions' and enumerates returned fields. Distinct from sibling tools like subscribe/unsubscribe.

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

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

Explicitly advises when to use: 'review what you're monitoring before adding more or to find an id to cancel'. Could mention alternatives but not necessary.

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 (all false), the description discloses rate limits (5 per identifier per day), a no-quota policy, claim_token handling for follow-up, and an internal review process (daily digests). This adds meaningful behavioral context that the annotations do not provide, and it contradicts nothing.

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?

Despite being long, every sentence provides essential operational guidance: purpose, use cases, exclusion boundaries, token handling, and rate limits. The description is front-loaded with the core purpose, then branches into conditional details, making it both complete and navigable.

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

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

Given the tool's complexity (multiple feedback types, claim_token semantics, cross-server exclusions, rate limiting) and the absence of an output schema, the description fully compensates. It explains return values, lifecycle of a report, quota behavior, and what not to include, leaving no critical gaps for an agent to guess.

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

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

The schema already covers all parameters (100%), but the description enriches semantics by explaining the claim_token round-trip ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed') and instructing on message content ('don't paste the end-user's prompt'). These details go beyond schema descriptions, so a score above baseline is warranted.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly enumerates the feedback types (bug, feature/data_gap, praise) and distinguishes these from filing with different MCP servers, making the tool's purpose unambiguous and differentiated 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?

Provides explicit when-to-use guidance (bug, feature/data_gap, praise), explicit when-not-to-use (tools from other MCP servers), and a fallback heuristic ('Not sure? Pipeworx tool names are the ones this connection lists'). This gives the agent clear decision criteria 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 indicate readOnlyHint, idempotentHint, destructiveHint, so the agent knows it's safe. The description adds valuable behavioral context: data source (CF analytics-engine), no PII, cache duration (5min-1h), and that it's self-aggregating. 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 compact with no wasted words. It front-loads the main output, then lists uses, then adds technical details. Every sentence earns its place, and the structure is logical.

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 1 optional parameter and no output schema, the description fully explains inputs (window), outputs (top tools, packs, volume), source, caching, and privacy. Nothing missing given the tool's complexity.

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

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

Schema coverage is 100% and includes a description for the window enum. The description adds semantic context: 'Shorter windows surface what's hot right now; longer windows show steady-state demand', which helps the agent choose the appropriate window beyond the schema's literal description.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' over a configurable window, with specific verb 'returns' and resource 'trending data on Pipeworx'. It distinguishes from siblings by emphasizing aggregation of other AI agents' calls, which is unique among sibling tools like discover_tools or 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 lists three use cases (discovering hot data, confirming canonical choice, seeing alignment) and explains trade-offs between short and long windows. However, it does not mention when not to use or directly contrast with siblings like discover_tools, which could be a related alternative.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent. The description adds extensive behavioral details: monotonicity checks, partition_sum, filler thresholds (3% gap), semantic anchor with Jaccard similarity, partition filter with placeholder fraction, and fill check comparing theoretical vs realizable edge with a warning not to trade when realizable edge <= 0. This far exceeds what annotations alone 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 slightly verbose (multiple paragraphs) but well-structured with section-like breaks and CAPS for key terms. It front-loads the purpose and uses clear separators for modes. While some details could be trimmed, the structure aids readability for an AI agent.

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

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

Given the tool's complexity and lack of output schema, the description thoroughly covers the response structure (opportunities[] array with fields, partition_check object in event mode, fill check behavior). It also references sibling tools for custom sizing. All necessary information for understanding inputs, outputs, and edge cases is present.

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

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

Schema coverage is 100% with both parameters documented. The description adds significant context beyond the schema: it explains the recommended use for each parameter (event for specific markets, topic for cross-event scanning) and provides examples of acceptable values (e.g., 'fed-decision-may-2026' for event, 'Fed rate decision' for topic). This helps the agent understand parameter semantics fully.

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: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) and provides examples of each, making it easy to understand what the tool does and differentiating it from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

The description explicitly guides when to use each mode: 'Call with NO args for a trending_scan', 'pass event for the strongest per-event partition_check', or 'topic for a themed cross-event scan.' It explains why cross-event mode is useful for catching patterns single-event misses, and directs users to polymarket_fill_risk for custom sizing. This provides clear decision criteria.

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

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by detailing caching behavior ('Cached 1h at the KV level keyed on all knobs'), response structure (by_segment, fed_candidates, _diagnostics), and model family logic (crypto_price, news_momentum, partition_overround, concentrated_longshot). No contradictions with annotations.

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

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

The description is long but well-structured: it starts with a clear summary, then breaks down the three segments, explains response fields, and lists parameter knobs. While dense, the front-loaded summary and logical organization help the agent parse key information. Minor redundancy could be trimmed without losing clarity.

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

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

Given the tool's complexity (9 parameters, no output schema, nested response structure), the description comprehensively covers all aspects: each parameter's meaning and defaults, the three response segments with model details, diagnostics that explain why segments might be empty, and the fed_candidates note. No critical information is missing for an agent to understand the tool's behavior and return values.

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

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

With 100% schema coverage, the description still adds significant value by explaining each parameter's purpose, default values, and usage context (e.g., 'Tradeable-edge filter' for max_spread_pp, 'Minimum half-Kelly fraction' for min_kelly). It also provides practical guidance such as 'Bump for very thin partitions; drop to 0 if you have a smarter fill model' for slippage_pp.

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 defines the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It distinguishes from sibling tools by specifying the use case 'what should I bet on today' and by describing the unique three-segment output structure (model_driven, structural_arbitrage, concentrated_longshot).

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

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

The description provides explicit guidance on when to use the tool ('Built for what should I bet on today') and includes details about tradeable-edge knobs (min_liquidity, max_spread_pp, min_kelly) that help the agent decide when to apply filters. However, it does not explicitly state when not to use the tool or suggest alternatives like polymarket_arbitrage or polymarket_edge_tracker.

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 (read-only, idempotent, etc.), the description adds critical behavioral details: uses daily snapshots, 60-day TTL, decay from daily closes not intraday, snapshot gaps, and full description of output structure.

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

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

The description is long but well-structured with sections for args, response fields, and limits. Could be more concise, but each sentence adds value.

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

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

Given 2 optional parameters, rich annotations, and no output schema, the description fully compensates by detailing the response structure (tracked[], expired[], snapshot_dates[]) and limitations (TTL, gap behavior). Complete for this tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. Description adds default values and clamping for days, and options for window, which is helpful but not beyond schema detail.

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: tracking edge persistence and decay over time, distinguishing it from a single-snapshot tool like polymarket_edges. It uses specific verbs (tracks, answers) and resource (edge persistence telemetry).

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

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

Provides clear context on when to use: to understand how long an edge has existed and its trend. It implies differentiation from polymarket_edges but does not explicitly state when not to use or list alternatives.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and no destructiveness. The description adds substantial behavioral context: it walks the order book ladder, computes VWAP, slippage, and verdicts. It also warns about forced directional risk from partial basket fills, which is critical behavior not captured by annotations. No contradiction.

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

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

The description is front-loaded with the core purpose and required parameters, then details each mode and return values. It is dense but efficient; every sentence adds value. Slightly long but appropriate for the tool's complexity.

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

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

Given the tool has two modes, several return fields, no output schema, and significant behavioral nuance, the description fully covers the needed information: return fields, mode selection, parameter roles, and risk warnings. It is complete for an agent to correctly select and invoke the tool.

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

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

Schema description coverage is 100% and already provides good parameter descriptions. The tool description adds value by explaining the two modes distinctively, default side auto-detection for baskets, and the interpretation of size_usd as 'settlement notional' for baskets. This enriches the schema descriptions meaningfully.

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 a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes two modes (single-market and basket). It uses specific verbs like 'walk the ladder' and lists concrete outputs (top_of_book, slippage, etc.), making the purpose unambiguous and differentiating it from siblings 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?

The description explicitly instructs when to use the tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also explains why (theoretical overround not capturable, partial fills cause directional risk), providing clear usage context and exclusions.

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, openWorldHint, idempotentHint, and non-destructive. The description adds critical context: compatibility_warning conditions (non-equivalent bet shapes, semantically unrelated events), temporal_alignment, and skipped counters for metric mismatches. This goes well beyond annotations, describing limitations and edge cases without contradiction.

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

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

The description is 227 words but well-structured with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). It front-loads the core purpose and then details modes, response, and safety. Minor redundancy ('pre-mapped ≠ tradeable' at end) but overall 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?

No output schema is provided, so the description carries the full burden of explaining return values. It explains leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, and skipped counters. For a tool with three optional parameters and complex cross-venue matching, the description is comprehensive and answers likely agent questions.

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

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

Schema coverage is 100% but description adds meaning: lists all topic values, explains that explicit parameters override the topic mapping, and mentions examples like 'KXFED-26OCT' and 'fed-decision-in-june-825'. This enhances the schema's enum description.

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

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

The description clearly states the tool computes the cross-venue spread between Kalshi and Polymarket. It distinguishes two modes (topic shortcuts and explicit parameters) and specifies the response includes leg-by-leg prices and matched spreads. It avoids tautology and uniquely identifies the tool among siblings.

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

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

The description explains when to use the topic mode versus explicit mode, and warns that most pre-mapped topics return compatibility_warning. It does not explicitly state when to avoid using the tool, but the warning about non-equivalent bet shapes serves as guidance. Excluding alternative tools is implied by the description's specificity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's main contribution is the scoping detail ('Scoped to your identifier') and the pairing with remember/forget. This adds meaningful context 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 well-structured and front-loaded with the primary action. It includes essential details without excessive verbosity, though it could be slightly more concise by merging some sentences.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: purpose, usage, scoping, and related tools. It is complete for effective agent 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?

With 100% schema coverage, the baseline is 3. The description adds value by explaining the behavior of omitting the key argument ('list all saved keys'), which clarifies the parameter's semantics beyond the schema's description.

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

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

The description clearly states 'Retrieve a value previously saved via remember, or list all saved keys' which provides a specific verb and resource. It distinguishes itself from sibling tools remember and forget by explicitly naming them.

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

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

The description explains when to use the tool ('to look up context the agent stored earlier') and implies alternatives via pairing instructions. While not explicitly stating when not to use, the context given is clear enough for an agent to decide.

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 states that mark_read:true flags returned events as read, implying a state change, but annotations include readOnlyHint:true indicating no modification. This direct contradiction makes the description misleading regarding 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?

The description is a single paragraph of four sentences, front-loading the purpose. It is reasonably concise, though readability could be improved with bullet points. No redundancy.

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

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

Despite no output schema, the description explains return fields and behavior for all parameters. It also gives an HTTP alternative for alternative use cases. The tool is well-contextualized 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%, and the description adds value beyond schema descriptions by explaining the effect of mark_read on future calls, the use of since as ISO timestamp, and the default for unread_only. The extra context justifies a score above baseline.

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

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

The description clearly states 'Pull fired events from your subscription feed' with a specific verb and resource. It details the returned fields (source, citation_uri, payload) and distinguishes from sibling tools like list_subscriptions or subscribe.

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

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

The description explains when to use (to get recent alerts, filter by type/since, mark_read for subsequent calls) and provides an HTTP alternative for scripts/dashboards. It lacks explicit 'when not to use' but is clear enough.

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

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

Annotations already declare readOnly, idempotent, etc. Description adds context on parallel calls to multiple sources, fallback logic, and soft-failure of USPTO, which are not covered by annotations.

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

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

Well-structured with examples, purpose, sources, parameters, return shape, and alternative. Slightly long but justified by complexity; front-loaded with user intents.

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

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

Covers return shape (structured changes grouped by source, total count, citation URIs) and handles edge cases like fallback and soft-failure. Lacks details on pagination or limits, but sufficient given no 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%, baseline 3. Description adds value by explaining accepted formats for 'since' (ISO date or relative shorthand) with examples, and clarifies that 'value' can be ticker or CIK.

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

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

Description clearly states the tool provides a change feed for a company over a time window, with specific verb 'fan out' and example queries. It distinguishes from sibling 'entity_profile' by contrasting temporal vs. static data.

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

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

Explicit guidance: when to use for 'what's new' queries, provides a direct alternative ('use entity_profile instead'), and explains fallback behavior between GDELT and GNews. Suggests typical monitoring values for 'since'.

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 beyond annotations: scoped by identifier, authenticated vs. anonymous persistence. Matches annotations (idempotentHint=true, destructiveHint=false). No contradiction.

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

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

Four sentences with front-loaded purpose. Every sentence adds value (purpose, usage, behavior, pairing). No redundancy.

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

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

Simple tool with 2 required params and no output schema. Description fully covers purpose, usage, persistence, and scope. Complete for agent selection.

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

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

Schema coverage 100% with descriptions for key and value. Description adds usage examples and clarifies key-value nature, but baseline is 3; extra context earns 4.

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

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

Description clearly states 'Save data the agent will need to reuse later' – a specific verb+resource combination. It also distinguishes from sibling tools (recall, forget) by noting pairing.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and provides examples (resolved ticker, target address, etc.). Also pairs with recall and forget for 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 indicate read-only, idempotent, and non-destructive behavior. The description adds significant behavioral detail beyond annotations: graceful degradation when GLEIF/OpenFIGI are unavailable, explicit reporting of unresolved identifiers instead of omission, labels showing the source for each identifier, and cascading internal lookups. These details materially help an agent anticipate edge cases.

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 well-structured: it front-loads the purpose with user-facing examples, includes a clear priority directive, then details each supported type and behavioral nuances. Every segment adds value for a complex tool with two distinct entity types and multiple fallback behaviors. While not as terse as a two-sentence description, the length is justified and not redundant.

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

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

Given the tool's complexity, the description is remarkably complete. It covers both supported entity types, input formats, expected identifiers, the unresolved-list behavior, graceful degradation, and the internal cascading of lookups. Since there is no output schema, the description carries the full burden of expressing return behavior, and it does so thoroughly.

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 provides 100% coverage with detailed descriptions for both parameters, meeting the baseline of 3. The description enriches this by explaining what each type resolves to (e.g., CIK/LEI/FIGI for company, RxCUI for drug) and clarifying input acceptance. This goes beyond literal schema format to give meaning about expected outcomes.

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 function: resolving user-spoken names to canonical/official identifiers needed by other tools. It provides concrete query examples (ticker, CIK, LEI, RxCUI) and explicitly says 'Use FIRST whenever you have a name but need an ID,' which distinguishes it from sibling tools like entity_profile and compare_entities.

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

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

Usage guidance is explicit: 'Use FIRST whenever you have a name but need an ID.' It also details acceptable input formats for each entity type (ticker/CIK/name for company, brand/generic for drug). However, it does not name alternative tools or state when not to use this tool, so it's clear context but no exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: it probes each entity internally using ai_visibility_check, ranks by score, and returns a structured result with score, confidence, and signal density per entity. No contradictions.

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

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

The description is three sentences, each serving a distinct purpose: main action, method and output, and use case. No unnecessary words; information is front-loaded and well-structured.

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

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

Given the lack of output schema, the description adequately describes the output format (ranked list with score, confidence, signal density per entity). All parameters are covered by schema descriptions, and the description adds the competitive audit context. The tool's behavior is fully explained.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by noting that the first entity is treated as the 'subject' for narrative. It also explains the purpose of the 'context' parameter implicitly through the example and use case.

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: comparing AI visibility across multiple entities, probing each with ai_visibility_check, ranking, and surfacing which is most/least recognized. It distinguishes from sibling tools like 'ai_visibility_check' (single entity) and 'compare_entities' (generic comparison).

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

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

The description provides a clear use case ('competitive AI-marketing audits') with an example question, implying when to use this tool over alternatives like the single-entity 'ai_visibility_check'. It lacks explicit exclusions or when-not-to-use guidance, but the context is sufficiently clear.

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

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

Annotations already declare read-only, idempotent, and non-destructive. Description adds transparency about composite nature, possible bundlephobia latency (5-30s), partial failures (sources_failed listed), and graceful degradation. 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?

Single paragraph but densely packed with information. Front-loads purpose and usage, then details outputs and caveats. Could be slightly more structured (e.g., bullet points) but efficient for the content.

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

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

No output schema, but description thoroughly explains return fields (summary block, advisories, links, alternative versions), failure modes, ecosystem scope, and latency. Covers all necessary context for agent to use correctly.

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

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

Schema coverage is 100% with both parameters well-described. Description adds value by clarifying scoped packages (e.g., '@types/node') and default version behavior (latest). This goes beyond schema, but schema already does a good job.

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

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

Clearly states the tool performs a composite check for npm packages across multiple sources (deps.dev, bundlephobia) and returns a summary. Differentiates from siblings by specifying npm ecosystem and purpose ('should I add this package?').

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 defines when to use: when agent asks about safety, popularity, size, or cost of adding a package. Also notes ecosystem limitations (npm only in v1) and mentions alternative tools for other ecosystems (deps.dev:version directly).

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds technical details: 'BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).' It also explains that each passage carries an offset for verification, providing deep behavioral insight.

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

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

Every sentence earns its place: starts with core purpose, then usage guidance, pairing with other tool, technical details. No fluff, well-structured, and front-loaded with the most important info.

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 that the tool 'get back the top-N passages with character offsets and similarity scores', covering return format. It also specifies input limits. For a tool with 3 parameters and no output schema, this is 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. The description adds context for parameters (e.g., 'pass the text you already pulled' and query examples), but does not significantly extend beyond the schema descriptions. It adds marginal value.

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

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

The description states 'Semantic search INSIDE a fetched record' with a specific verb (search) and resource (fetched record). It distinguishes from siblings by mentioning a pairing with ask_pipeworx_grounded, clarifying that search_within is for searching inside a record, not for other use cases.

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

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

Explicitly states when to use: 'Use when the record is too big to cram into the prompt' and provides an alternative: 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document.' This gives clear contextual 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=false, idempotentHint=true), the description adds valuable behavioral context: requires OAuth, returns subscription id, details type-specific params, and notes SMS caps and phone verification. It could clarify idempotency given the annotation, but overall adds significant 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 front-loaded with the main purpose and efficiently covers key details. While slightly lengthy, each sentence earns its place. A minor trim could be made, but overall structure is clear.

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

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

Given the tool's complexity (3 params, nested objects, 5 enums, no output schema), the description covers authentication, return value, and most delivery modes. However, it misses two subscription types and the webhook channel, leaving gaps for an agent to fully understand the parameters.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds examples and constraints (e.g., SMS cap) for three of the five enum types but omits 'patent_grant' and 'clinical_trial' and omits the webhook delivery channel. It provides some added value but is incomplete relative to 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 a specific verb+resource: 'Create a proactive monitoring subscription to a live-data event stream.' It clearly distinguishes from siblings list_subscriptions, unsubscribe, and recent_alerts by describing the creation action and the resulting subscription id.

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 (for proactive monitoring) and provides context like requiring an OAuth account and mentioning alternative delivery mechanisms (feed vs email/sms). However, it does not explicitly exclude alternatives or state when not to use this tool over siblings.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds value by explaining the output format (category-bucketed example questions with tool+argument shapes) and that it draws from a live catalog, which is behavior 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 informative but slightly verbose. It front-loads common user questions and then explains output, which is good. However, some repetition could be trimmed without losing clarity.

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

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

Given the tool's simplicity (0 required params, no output schema), the description fully covers what the tool does, when to use it, and what to expect. It leaves no ambiguity 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% with a single optional parameter. Description adds meaning by listing example topic values ('finance', 'pharma', etc.) and explaining behavior when omitted ('full spread'). This provides context beyond the schema's generic 'Optional focus area'.

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

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

The description clearly states it is an onboarding entry point that returns category-bucketed example questions, with specific verb 'returns' and resource 'example questions' and 'tool + argument shape'. It distinguishes from siblings like ask_pipeworx by positioning as the first tool to use when unsure.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do' and explains when to pass a topic vs no arguments. Also mentions it teaches how to call meta-tools, giving clear context for when to use this tool versus others.

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

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

Discloses row is deactivated not deleted and historical events stay available, adding context beyond annotations (readOnlyHint false, destructiveHint false, idempotentHint true). No contradiction.

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

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

Three sentences, no redundancy, front-loaded with core action, each sentence adds essential info.

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

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

Fully adequate for a simple 1-param tool with no output schema; covers purpose, ownership, and behavior without missing critical 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?

Parameter id described as 'Subscription id (uuid) returned by subscribe', adding origin context beyond schema description (100% coverage).

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

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

Desc states 'Cancel a subscription by id', specifies ownership enforcement and deactivation behavior, clearly distinguishing from subscribe and list_subscriptions 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?

Explicitly notes ownership enforcement ('you can only cancel your own subscriptions') and deactivation effect, guiding appropriate use; no explicit alternative mention but contextual clarity with sibling tools.

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

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

The description goes well beyond annotations by detailing the two routing pipelines (SEC EDGAR/XBRL vs. grounded), enumerating exact verdicts (confirmed, refuted, etc.), and crucially clarifying that could_not_verify is not evidence and unsupported means no source exists. This is 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 well-organized, starting with trigger phrases, then purpose, pipeline logic, return values, and a critical caller warning. Every sentence delivers operational value, though the initial trigger phrase list is somewhat redundant and 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?

With no output schema, the description fully covers return values and semantics: the verdict types, pipeworx:// citation, error handling, and unsupported vs. could_not_verify. It also explains efficiency gain over sequential calls, leaving little ambiguity for the agent.

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

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

Schema coverage is 100%, so both parameters already have clear descriptions. The tool description adds context about claim processing (financial vs. other) but does not introduce new parameter syntax or constraints. This is the baseline for high schema coverage.

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

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

The description specifies a clear verb-resource pairing: 'natural-language claim verification against authoritative sources.' It lists trigger phrases and defines the return verdicts, which distinguishes it from sibling tools like ask_pipeworx (Q&A) and deep_research (open-ended investigation).

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: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also distinguishes between financial and non-financial claim handling. However, it does not name alternative tools for non-claim tasks, so it stops short of a full 5.

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