Npi Registry

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds crucial behavioral context: default free model, BYO key for Anthropic with direct payment, and the structure of the return value. 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 a single concise paragraph, front-loaded with the main purpose. Every sentence adds value, explaining defaults, optional behavior, return structure, and use cases 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?

Given the tool's moderate complexity (4 parameters, no output schema), the description adequately covers inputs, behavior, return values, and use cases. The annotations provide strong safety guarantees, so the description is complete for an agent to use correctly.

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

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

Schema coverage is 100% with descriptive parameter descriptions. The tool description further enriches meaning by explaining the default model, when the _apiKey is needed, and how context helps disambiguate. Adds significant value beyond the schema.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and returns a visibility score. It uses specific verbs ('probe', 'score') and distinguishes from sibling tools by focusing on visibility auditing rather than general Q&A or research.

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

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

The description lists use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) but does not explicitly state when to avoid this tool or contrast it with alternatives like compare_entities or deep_research. Provides 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 establish a safe profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely non-obvious behavioral context: it is an orchestrator that routes to 5,798 sub-tools, auto-fills arguments, and returns stable pipeworx:// citation URIs — none of which is inferable from the annotations. No contradiction with the read-only/idempotent hints.

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

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

Well front-loaded: the most important instruction ('PREFER OVER WEB SEARCH') leads, followed by scope, mechanics, triggers, examples, and routing alternatives in logical order. Nearly every sentence earns its place, but a garbled fragment ('default entry point, works on every tier, one fast call. Step up only when needed:') reads like concatenated bullet points, and the example list is slightly long.

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

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

For a high-complexity router over thousands of sources, the description is unusually complete: it covers purpose, domain scope, trigger phrasing, sibling routing, and — important since there is no output schema — the return shape (structured answer with citation URIs). Remaining gaps are minor: no failure modes or known limitations, and the tier/latency claim is garbled. Annotations carry the safety profile, so nothing critical blocks correct invocation.

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

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

Schema coverage is 100% and the question parameter is fully documented with its five aliases, so the baseline is 3. The description adds value by specifying what kinds of questions to pass — trigger phrases plus six concrete examples ('current US unemployment rate', 'Apple's latest 10-K', 'adverse events for ozempic') — which goes beyond the schema's generic 'Your question or request in natural language'.

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

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

States a specific function: routes natural-language questions to the right one of 5,798 tools across 1,517 verified sources, fills arguments, and returns structured answers with pipeworx:// citation URIs. It explicitly differentiates from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for narrower/broader needs, so an agent can tell them apart without opening their schemas.

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

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

Opens with an explicit priority rule ('PREFER OVER WEB SEARCH'), enumerates covered domains (SEC, FDA, FRED/BLS, USPTO, ATTOM, news, clinical trials, etc.), lists trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), and explicitly says to use it 'even if web search could also answer it'. It closes with named alternatives and the conditions that select them: single citation-grounded answer → ask_pipeworx_grounded; broad/multi-part fan-out → deep_research.

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

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

The description goes well beyond the readOnly/openWorld/idempotent annotations by explaining the experimental release status, the current no-candidate state, parity with ask_pipeworx right now, and the fact that results are compared against the stable router. It also removes a likely misconception by stating 'Falls back to nothing — this IS a full working router.' No contradiction with annotations exists.

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 identity, then usage, then behavioral caveats, and every sentence contributes. It is slightly longer than necessary, with details like the retirement date and the repeated 'same ... same ... same' clause, but the added context is genuinely useful for a beta tool.

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

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

For a variant tool, referencing ask_pipeworx for exact usage and response shape is reasonable and effective. The description covers current behavior, parity, experimental status, and fallback expectations. It relies on the agent knowing or consulting the ask_pipeworx sibling for the precise response format, which is an acceptable but minor dependency.

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

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

Schema description coverage is 100%, so the schema already fully documents the question parameter and its aliases. The description only says 'same arguments' as ask_pipeworx, which adds no parameter-level meaning beyond what the schema provides. This is a fair baseline-3 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 identifies the tool as the beta version of ask_pipeworx, a universal router over 5,798 tools with identical arguments and response shape. It distinguishes this experimental variant from the stable ask_pipeworx sibling, and the instruction 'Use it exactly like ask_pipeworx' anchors the intended action.

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

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

The description gives a clear use condition: use it like ask_pipeworx 'when you want the newest routing,' and it explicitly names the stable router as the comparison point. It stops short of an explicit when-not-to-use instruction, such as 'for stable/production results, use ask_pipeworx instead,' though that is strongly implied by the beta framing.

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 read-only/idempotent annotations, it discloses exact success and refusal response structures, refusal reason enums, evidence extraction from verbatim quotes, and the extra LLM call cost. No behavioral 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?

Dense but well-organized: purpose first, then mechanics, then return shape, then usage guidance. Every sentence contributes either behavioral or routing information with no filler.

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

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

Despite missing an output schema, the description fully documents both success and refusal outputs, source/behavior, cost tradeoff, and appropriate contexts. The routing reference to ask_pipeworx plus the refusal enum makes the definition complete for correct invocation.

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

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

Schema coverage is 100% and the schema already describes 'question' with aliases, so the description is not required to add parameter details. It does not add meaning beyond the schema; baseline 3 applies.

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

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

Description opens with a concrete purpose: 'Hallucination-resistant answer mode for high-stakes reads' and explicitly contrasts with 'Same routing as ask_pipeworx' while naming the grounded/evidence behavior. This clearly differentiates it from the ask_pipeworx sibling.

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 ('whenever an answer will be quoted, cited, or acted on...') and an explicit alternative ('prefer ask_pipeworx for casual lookups') with cost-based rationale. This is strong routing guidance.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) already indicate safe, non-destructive behavior. The description adds substantial behavioral context: market resolution via slug/URL/text, classifier fan-out with specific sources, response shapes (market analysis, evidence, resolver contract), safety (low-confidence short-circuit, closed market handling, wide-spread markers), and resolution-rule risk parsing. No contradictions with annotations.

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

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

The description is very long but well-structured with labeled sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.) and uses dashes for bullet points. However, it is verbose and could be more concise. Every sentence adds value, but the length may hinder quick scanning.

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

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

Given the complexity of the tool (multi-resource fan-out, classification, resolution), the description covers all critical aspects: input formats, classifiers with examples, response shapes for market, analysis, evidence, resolver contract (match confidence, alternatives, suggestions), parent event extraction, news fallback, safety edge cases (low confidence, closed markets, wide spreads), and resolution rules. No output schema exists, but the description explains returned fields sufficiently.

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 meaning: for 'market', it explains it can be a slug, URL, or question text; for 'depth', it defines 'quick' vs 'thorough' with default; for 'include_raw', it explains the trade-off and use cases. This enhances 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 begins with a clear verb-resource-action statement: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies that it resolves markets, classifies bets, and returns evidence packets with comparisons. Usage examples ('should I bet on X') and the classifier list further clarify the purpose.

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

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

The description explicitly states when to use the tool ('Use for should I bet on X...') and provides classifiers and fan-out examples. It explains safety mechanisms (low-confidence matches, closed markets) and resolution rules. While it doesn't explicitly state when not to use it, the context from sibling tools implies differentiation.

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

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

Annotations already indicate read-only, open-world, and idempotent behavior. The description adds substantial detail: specific data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. It does not discuss error handling or response format but provides good 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 a single dense paragraph that front-loads with query examples. It contains no filler and every sentence adds value, though it could be slightly more structured (e.g., bullet points) for easier parsing. Still concise enough 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 no output schema, the description covers essential aspects: entity types, data sources, sorting, citations, and efficiency gains. It lacks details on error scenarios and response structure but is complete for typical use.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds significant meaning: for type it explains what data each enum value retrieves, and for values it gives concrete examples (tickers for company, drug names for drug) and reinforces the 2-5 limit.

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 in a single call, with explicit example queries. It distinguishes from siblings by emphasizing preference over sequential lookups, and the sibling list includes entity_profile which is a single-entity tool.

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

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

The description provides clear guidance on when to use the tool (comparing 2-5 entities) and strongly recommends it over sequential lookups. It does not explicitly cover when NOT to use, such as limits beyond 5 entities, but the 2-5 range is stated.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavior beyond that: auth requirements, paid tier, parallel routing, gap reporting with never-invented guarantees, contradiction scans, semantic excerpting, and timing expectations. No contradiction with annotations.

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

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

The description is dense and front-loaded with the most critical constraint (paid account) before scope. Every clause earns its place for a tool this complex, though it could benefit from bullets or clearer separation of auth, depth, output, and timing. Still appropriately sized 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?

For a tool with no output schema, the description covers the return packet shape (evidence, confidence, source, fetched_at, citation_uri), gaps behavior, contradictions, citation resolvability, latency, auth, and alternatives. Nothing essential is missing for an agent to decide whether and how to invoke it.

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

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

Schema coverage is 100% and depth is already documented in the schema. The description adds useful context: thorough requires a paid plan, depth tiers map to iterative hops, and natural-language multi-part questions are explicitly supported. This goes beyond the schema without being redundant.

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

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

The description clearly identifies deep_research as a grounded multi-source research tool that decomposes questions, routes them across thousands of tools, and returns a findings packet. It explicitly distinguishes itself from open-web search and from single-lookup ask_pipeworx, so its purpose is unmistakable.

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

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

The description states when to use it (hood/multi-part questions over structured data), when not to (single lookup: use ask_pipeworx instead), and the account prerequisite with a fallback. The depth tiers are also described with their practical differences. This is explicit routing guidance.

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

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

Annotations provide readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns top-N relevant tools with names, descriptions, schemas, and that results are ready to call directly. No contradictions, and it adds useful behavioral context beyond annotations.

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

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

The description is a single paragraph that efficiently states the purpose, lists domains, and explains output. It is front-loaded and every sentence adds value, though it could be more structured with bullet points.

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 compensates by detailing the return format (names, descriptions, schemas). It explains the tool's role as a first-step discovery tool. The limit parameter is noted in schema but not elaborated in description. Overall, it is sufficiently complete for a discovery tool with good annotations.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds value by explaining that results include schemas and are ready to call, but does not add meaning beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool finds tools by describing data or task, with a specific verb and resource. It distinguishes itself from siblings by being a discovery tool, and lists many domains it covers, making its purpose unambiguous.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear when-to-use guidance and implies it is for exploration before specific 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 mark the tool readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that. It discloses soft-failure for the USPTO patents source, expected empty results for companies with only small-molecule drugs, the GDELT→GNews fallback for news, and the meaning of sources_used/sources_failed. This is exactly the kind of behavior an agent needs to interpret results correctly.

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

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

The description is long, but the tool is genuinely complex, with many sources and edge cases that need explanation. It front-loads query examples and the key directive, and the dense semicolon-separated list earns its place. It loses a point for some redundancy with the schema and for being a single wall of text that could benefit from light structuring.

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

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

There is no output schema, so the description carries the full burden of explaining return values — and it does so thoroughly. It enumerates every returned section (cik, recent_filings, fundamentals, patents, fda_products, hiring, etc.), explains URI formats, describes failure semantics, and tells the agent what to pass and what to expect for private companies. Nothing critical is missing for correct invocation and result interpretation.

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 repeats what the schema already states: value can be a ticker, zero-padded CIK, or company name, and type accepts 'company' or 'ticker' interchangeably. It adds minor context around name resolution via SEC EDGAR, but no meaningful parameter semantics beyond the schema.

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

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

The description opens with natural-language triggers ('Tell me about X', 'brief me on Tesla') and states the core function: 'full cross-source profile of a US public company in ONE parallel call.' It names the resource (company) and verb (profile), and explicitly differentiates itself from 'chaining single-pack SEC/XBRL/news lookups.' This leaves no ambiguity about what the tool does.

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

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

The description is explicit about when to use it: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also covers edge-case usage, such as private companies returning resolved:false with an explanatory notes line, and clarifies that empty sections are real 'no data,' not bugs.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds use-case context but no further behavioral traits like error handling or side effects.

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 all key information front-loaded. Every sentence adds value.

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

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

Sufficient for a simple tool with one parameter and no output schema. Mentions related tools and usage context.

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

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

Schema coverage is 100% with a clear description for the only parameter. The tool description adds no extra meaning beyond 'memory key to delete'.

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

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

The description clearly states the action (delete a stored memory by key) and distinguishes it from siblings by referencing 'pair with 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?

Provides explicit when-to-use scenarios (stale context, task done, clear sensitive data) and references related tools, but does not mention when not to use.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds details: fetches page, extracts title/description/key links, emits single text blob. Contradiction false.

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

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

Two sentences plus a bulleted list of use cases, no redundancy. Purpose 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?

Tool is simple with rich annotations and schema. Description covers purpose, behavior, output, and use cases. No missing information.

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

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

Schema coverage is 100% with descriptions for both parameters. Description does not add extra meaning beyond what schema provides, so baseline 3.

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

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

The description clearly states it generates an llms.txt file for a URL, explaining extraction and output format. It distinguishes from siblings like scan_competitor_ai_presence by focusing on file generation.

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: indexing client sites, drafting own project files, auditing competitors. Provides clear context for when to use, but no explicit when-not-to 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds no behavioral context (e.g., response format, performance) beyond what annotations provide. A score of 3 reflects adequate but not enhanced transparency given annotation presence.

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, concise sentence that immediately conveys the core purpose. No extraneous information; every word earns its place.

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

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

Given the tool's simplicity (single parameter), presence of output schema, and thorough annotations, the description suffices. It covers what the tool does and the key constraint. Minor improvement could mention that it returns a full provider object, but output schema handles that.

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%: the input schema already describes the 'npi' parameter as '10-digit NPI'. The tool description repeats this without adding further details (e.g., format or validation rules). Thus, no additional semantic value beyond schema.

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

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

The description clearly states the action ('Fetch') and the specific resource ('provider by 10-digit NPI'), including a precise constraint (10-digit). This distinguishes it from sibling tools like 'entity_profile' that might retrieve provider info by other means.

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that this is the tool for NPI-based lookups or that 'entity_profile' might be used for other identifiers. The agent receives no help in disambiguating tool choice.

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 safety (readOnlyHint, no destructiveHint). The description adds value by listing specific return fields, but lacks details like pagination or rate limits. 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 two concise sentences: purpose and return info first, then usage guidance. No wasted words, front-loaded with key details.

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

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

Given the simple tool (1 optional param, no output schema), the description covers purpose, usage, return fields, and integrates annotations. It is fully sufficient for an agent to invoke correctly.

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

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

Parameter include_inactive is fully described in schema (100% coverage). The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'list' and resource 'subscriptions', specifies returned fields, and distinguishes it from siblings like subscribe/unsubscribe by focusing on listing active subscriptions.

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

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

The description advises when to use: 'to review what you're monitoring before adding more or to find an id to cancel'. This provides clear context, though it could be more explicit about when not to use.

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

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

Annotations only indicate readOnlyHint=false, but the description adds substantial behavior: the claim_token flow for later retrieval, a 5-per-day rate limit, 'free and doesn't count against quota', daily reading by the team, and the roadmap impact. This far exceeds what structured annotations provide and reveals the tool's full life cycle.

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 ~150 words but every sentence earns its place: types, exclusions, claim_token usage, rate limit, and content guidance. It is front-loaded with the core purpose and uses punctuation and examples effectively for readability. No fluff or repetition.

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

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

For a tool with 4 optional params, 0 required, and no output schema, this description covers all nuances: feedback categories, optional context structure, claim_token retrieval, rate limiting, and the critical scope boundary (only Pipeworx connection tools). An agent will know exactly when and how to invoke it, and what to expect in return.

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 semantic baseline is met. The description adds critical extra guidance for claim_token (pass it back later with no other arguments to read status), which is a behavioral constraint not in the schema. Slight benefit over baseline, though the schema already documents each parameter well.

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

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

The description opens with a specific verb-resource pair ('Tell the Pipeworx team') and enumerates concrete feedback types (broken, missing, needs to exist). It distinguishes Pipeworx feedback from sibling tools by explicitly limiting it to tools served by this connection, making the purpose unmistakable.

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

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

It gives explicit when-to-use scenarios (bug, feature/data_gap, praise) and an explicit exclusion (other MCP servers' tools), plus guidance on what to write (describe in terms of Pipeworx tools/packs, don't paste the end-user prompt). This is exemplary usage direction with clear alternatives and boundaries.

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

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

Annotations already convey readOnly, idempotent, non-destructive. Description adds valuable context: data source (CF analytics-engine), no PII, cached 5min-1h. Provides transparency beyond annotations without contradiction.

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

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

Concise three-sentence structure with front-loaded main action. Every sentence adds value: result, use cases, data source/caching. No fluff.

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

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

For a simple read-only tool with one optional parameter, the description covers purpose, usage guidance, parameter semantics, and data source/caching. No output schema needed given the simplicity and annotations.

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

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

Schema coverage is 100% for the single window parameter. Description adds semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This enhances understanding beyond the enum values.

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 returns top tools, packs, and call volume over configurable windows. Verb ('returns') and resource ('Pipeworx trending data') are specific. Distinct from sibling tools like ask_pipeworx and deep_research, which have different purposes.

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

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

Explicitly lists three concrete use cases (discovering hot sources, confirming canonical choice, seeing alignment). Does not directly state when not to use, but use cases imply boundaries. Caching behavior mentioned adds guidance on data freshness.

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

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

Despite annotations already indicating read-only, idempotent, and non-destructive behavior, the description adds rich behavioral context: semantic anchor (Jaccard similarity), partition filter (placeholder slugs), fill check against live CLOB depth, and realizable edge warnings. No contradictions with annotations.

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

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

The description is well-organized with sections for each mode and detailed subpoints. Every sentence adds value, covering modes, parameters, internal checks, output, and limitations. Despite length, it is information-dense and efficiently 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 tool's complexity and lack of output schema, the description thoroughly covers all aspects: modes, parameters, internal logic (Jaccard, partition filter, fill check), output fields, and links to related tools. It leaves no significant gaps.

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

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

The input schema already describes each parameter, but the description adds significant meaning: examples of slugs, explanation of how event walks child markets and checks partition, and how topic searches related events. It clarifies the internal logic and output.

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 between two modes (trending_scan, event, topic) and contrasts with sibling tools like 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 provides explicit when-to-use guidance for each parameter: no args for trending scan, event for specific market, topic for cross-event scanning. It also directs users to polymarket_fill_risk for custom sizing, effectively differentiating from 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, and destructiveHint. The description adds valuable behavioral context: caching behavior ('Cached 1h at the KV level keyed on all knobs'), response structure details (by_segment, diagnostics), and edge case handling (e.g., Fed bets excluded from ranking). This goes beyond annotations.

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

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

While lengthy, the description is well-structured with clear sections and front-loaded purpose. Every sentence provides useful information without redundancy. It could be slightly more concise, but the density of information justifies the length.

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

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

The description fully addresses the tool's complexity (9 parameters, no output schema) by explaining response segments, model families, diagnostics, and parameter interactions. It covers edge cases like empty segments and Fed bets. No gaps are evident.

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 each parameter described. The description adds extra context such as 'Polymarket has zero trading fees as of 2024 but bid/ask + thin depth typically eats 20-50bp per trade' for slippage_pp, and explanations of how filters interact (e.g., min_partition_leg_kelly details). This enhances understanding beyond the schema.

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

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

The description clearly states it scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by explicitly framing itself as a discovery tool for 'what should I bet on today'.

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

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

The description provides context for when to use the tool (discovery of opportunities) but does not explicitly state when not to use it or compare it to alternatives like polymarket_edge_tracker for tracking historical edges or polymarket_arbitrage for pure arbitrage. Usage guidance is implied rather than explicit.

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

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

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), description details response structure (tracked[], expired[], snapshot_dates[]) with field meanings, computational assumptions (daily closes of edge_pp_net, net default slippage, not intraday), and data gaps behavior. No contradictions with annotations.

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

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

Description is long but well-structured: starts with purpose, then explains response in three arrays with clear labels, and ends with limits. It is front-loaded with the core question. Slight verbosity in the middle but necessary for clarity.

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

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

With no output schema and 2 well-documented parameters, the description provides a complete picture: what the tool returns (tracked, expired, snapshot_dates), field meanings, and limitations (60-day TTL, decay computation). No gaps remain for an agent to invoke correctly.

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

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

Schema coverage is 100% with both parameters fully described in schema (defaults, ranges). Description adds no new semantic value beyond restating the schema's info (e.g., days lookback and window family). Baseline 3 is appropriate.

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

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

Description clearly states it provides edge persistence and decay telemetry, answering a specific question: 'how long has this edge existed and is it shrinking?' It distinguishes from sibling tool polymarket_edges by focusing on time-series and decay, not just current 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 implies when to use this tool versus alternatives (e.g., polymarket_edges for current edges) by focusing on history and decay. It provides limits like 60-day snapshot TTL, but doesn't explicitly list when-not-to-use or name alternatives directly.

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

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

Discloses behavioral traits: walks the ladder, returns specific fields (verdict, thin_legs, forced_directional_risk). Warns about partial basket fills and thin books. Annotation readOnlyHint is consistent.

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?

Information-dense but slightly verbose. Front-loaded with purpose and key warnings. Uses capitalization for emphasis, but could be more streamlined.

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?

Comprehensive: covers two modes, parameters, return fields (including edge cases like verdict, thin_legs). No output schema, so description compensates fully. Includes risk warnings.

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?

Adds meaning beyond schema: explains single-market vs basket modes, default sides, interpretation of size_usd differently per mode. Schema coverage 100%, but description provides essential context.

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

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

Clear and specific: checks realizable-vs-theoretical edge against live CLOB depth. Distinguishes single-market vs basket modes. Differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by stating when to use it before 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?

Explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains why (partial fills convert arb into directional risk).

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, and the description does not contradict those. It adds exceptional behavioral detail: Kalshi fees are not modeled, spreads are gross not net, matching is keyword-based not source-verified, unknown legs are never paired, temporal_alignment null does not mean aligned, and candidates can be returned with warnings. This is far beyond minimal disclosure.

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 densely informative, with clear section labels like TWO MODES, RESPONSE, and SAFETY FIELDS, and the core purpose is front-loaded. Some repetition exists around warning fields and compatibility codes, but every sentence adds practical guidance. It is appropriately sized for a tool with this many caveats and output nuances.

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 no output schema, the description carries the full burden of explaining the response, and it does so thoroughly: top_spreads_pp, compatibility_warning/codes, per-entry flags, skipped_unclassified, low_confidence_pairs, temporal_alignment semantics, fees_note, and skipped counters are all covered. An agent has enough context to invoke the tool correctly and interpret its results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: it explains that topic auto-fetches matching events, that kalshi_event_ticker and polymarket_event_slug override the topic-mapped sides, and that both modes run the same matcher with the same disclosures. It does not add validation constraints or format details, so it stops short of 5.

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

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

The description clearly states the tool's purpose: computing cross-venue spreads between Kalshi and Polymarket for the same resolving question. It names the two operating modes and the key output. However, it does not explicitly differentiate itself from sibling tools like polymarket_arbitrage, polymarket_edges, or polymarket_fill_risk, so an agent would need to infer which one fits the task.

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

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

The description gives clear guidance on the two modes, explaining when to use topic shortcuts versus explicit ticker/slug pairings, and notes that overrides replace the topic-mapped side. It also warns that most pre-mapped topics return compatibility warnings and that pre-mapped does not mean tradeable. It does not name sibling tools or explicitly state when not to use the tool, but the internal mode guidance is strong.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by clarifying scoping (anonymous IP, BYO key hash, account ID) and the behavior of omitting the key to list all keys. No contradictions with annotations.

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

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

The description is three sentences, each contributing essential information: main action, use case, scoping, and complementary tools. No filler or redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: purpose, usage, scoping, and related tools. No gaps.

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

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

Schema coverage is 100% as the single parameter 'key' is described in the schema. The description rephrases the same info ('omit the key argument') without adding new meaning beyond context. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves a value saved via remember or lists all keys if no key is provided. It uses specific verbs ('Retrieve', 'list') and identifies the resource (saved keys/values). It distinguishes from siblings like 'remember' and 'forget'.

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

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

The description explains when to use the tool: to look up context stored earlier without re-deriving it. It mentions scoping and pairing with remember/forget. However, it does not explicitly state when not to use it or compare to other siblings beyond the memory triad.

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

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

Annotations indicate read-only, but the description discloses mark_read side effects, aligning with idempotentHint. No contradiction; description adds transparency about the optional state change.

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 (5 sentences) and front-loaded with the main action. It efficiently covers purpose, parameters, and output 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?

Despite no output schema, the description explains return fields. It covers filtering, state management, and alternative access. Lacks pagination details but sufficient for a read tool.

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

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

Schema coverage is 100%, and description adds value by giving examples (e.g., 'sec_8k'), explaining the timestamp format, stating default limit (50), and clarifying the mark_read behavior.

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

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

The description clearly states the tool pulls fired events from a subscription feed and returns recent alerts with specific fields. It lacks explicit sibling differentiation but is specific enough to understand the tool's role.

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 guidance on filtering by type and timestamp, using mark_read for state management, and mentions polling. Does not explicitly exclude scenarios or compare to siblings, but offers practical context.

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

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

The description discloses multiple behavioral traits beyond annotations: parallel call to multiple sources, fallback behavior, soft-fail for USPTO, date parsing options, and structured output format with grouped changes and citation URIs. This adds significant context beyond the readOnlyHint and other annotations.

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

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

The description is long but well-structured, starting with example queries and proceeding logically through sources, parameters, and return format. Every sentence adds necessary context, though a slight tightening could improve conciseness.

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

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

Given the complexity of the tool (multiple sources, fallback, date parsing), the description is highly complete. It explains sources, fallback logic, date format, output structure, and provides a clear alternative tool, fully equipping an agent to use it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by providing examples for the `value` parameter (ticker or CIK), explaining the only accepted `type` (company), and recommending typical monitoring periods for `since`. These enrich the schema 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 that the tool provides a change feed for a company in a recent time window, using example queries like "What's new with X". It distinguishes from sibling tool `entity_profile` by specifying that the latter is for static profiles regardless of window.

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

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

The description gives explicit when-to-use guidance, including example queries and a specific alternative (`entity_profile`). It also provides parameter advice (e.g., 'Use "30d" or "1m" for typical monitoring') and explains fallback logic (GDELT preferred, GNews when rate-limited).

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 idempotentHint=true and destructiveHint=false. The description adds important behavioral details beyond annotations: scoped by identifier, persistent vs anonymous sessions, 24-hour retention for anonymous. 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: purpose/usage, when to use, and behavioral details. No redundant or extraneous text. Front-loaded with the core action.

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

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

Given the simple tool (2 params, no output schema), the description covers all necessary context: purpose, usage triggers, scope, persistence, and pairing with other tools. No gaps.

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

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

Schema coverage is 100% with parameter descriptions. The description adds value by giving key naming conventions (e.g., 'subject_property') and clarifying value as 'any text'. This provides contextual guidance beyond the raw schema.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later'. It provides concrete examples of what to store (resolved ticker, target address, preferences) and explicitly distinguishes from siblings 'recall' and 'forget'.

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

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

The description gives explicit guidance on when to use: 'Use when you discover something worth carrying forward'. It also tells what not to do indirectly by specifying it's for data the agent needs to reuse. Pairs with recall and forget, providing a complete usage context.

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

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

Annotations already declare readOnly/openWorld/idempotent, and the description goes well beyond them. It discloses graceful degradation when GLEIF/OpenFIGI are unavailable, ambiguous matches returning figi_candidates instead of asserting, explicit unresolved fields, and internal cascading across lookup endpoints. These are exactly the non-obvious behaviors an agent needs to interpret results correctly.

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

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

The description is front-loaded with purpose and realistic query examples, then organized by supported types and caveats. It is long, but the tool's complexity — two entity types, multiple identifier sources, fallback behavior — justifies most of the content. A few repetitive example phrasings could be trimmed, so it stops just short of exemplary 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?

Despite having no output schema, the description covers accepted inputs, canonical identifiers per type, ambiguity handling, unresolved output behavior, source labeling, and external dependency failure modes. For a two-parameter read-only resolver, an agent has enough information to select, invoke, and interpret the tool correctly.

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

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

Even though schema coverage is 100%, the description adds real semantic value: ISIN as an accepted input, its resolution path through GLEIF, and the critical bond-specific instruction to pass the issuer name exactly as printed without trailing security-class words. This meaningfully extends the schema's parameter documentation.

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

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

The description states a specific core action: resolve a user-spoken name to canonical/official identifiers that other tools require as input. The extensive query examples and explicit supported types make the tool's role unambiguous. It also distinguishes itself from downstream consumer tools by saying 'Use FIRST whenever you have a name but need an 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 gives an explicit when-to-use rule: 'Use FIRST whenever you have a name but need an ID.' It also explains that the tool replaces 2-3 manual lookups, which helps an agent decide when to call it. However, it does not name alternative tools or state when not to use it, so the exclusion guidance is incomplete.

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 explains probing process, ranking, and output details (score, confidence, signal density) beyond what annotations provide. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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

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

Two concise sentences with front-loaded purpose. Every sentence adds value without redundancy.

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

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

Covers purpose, method, parameters, return value (ranked list with specific fields). No output schema but description sufficiently explains expected results. Complete for a tool with 4 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?

Adds meaningful context beyond schema: first entity treated as subject for narrative, default model is workers-ai, anthropic requires API key. Schema coverage is 100%, but description enriches each parameter's usage.

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

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

Specific verb 'Compare AI visibility' with clear resource 'multiple entities side-by-side'. Distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison) by specifying the use of ai_visibility_check probes and ranking.

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 use case for competitive AI-marketing audits with a concrete example question. However, does not explicitly state when not to use or mention alternatives beyond the example.

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

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

Annotations already indicate readOnly, idempotent, not destructive. The description adds significant behavioral details: partial failure handling, bundlephobia timeout (5-30s), and graceful degradation with sources_failed.

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

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

The description is dense and well-structured. The first sentence summarizes the tool's purpose. However, some parts (e.g., listing output fields) could be slightly more concise. Still efficient overall.

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

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

Despite no output schema, the description fully explains the return structure (summary, per-advisory, links, alternative versions) and behavior on failure. Adequate for a tool with 2 parameters and no nested objects.

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 describes both parameters with 100% coverage. The description adds that version defaults to latest when omitted, providing minor extra context 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 the tool performs a composite check for adding npm packages, combining deps.dev and bundlephobia. It distinguishes itself from siblings by specifying the exact use case and scope.

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

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

Explicitly states when to use: when an agent asks about safety, popularity, size, or cost of an npm package. Also notes limitations (NPM only in v1) and alternatives for other ecosystems.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, so the description's additional note about filter requirements adds useful context without contradicting annotations. The tool's safety profile is effectively communicated.

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

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

The description is two sentences: the first states the general purpose, the second adds a critical usage constraint. No wasted words, front-loaded with key information.

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

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

Given the high schema coverage, existence of an output schema, and annotations, the description is adequately complete. It covers the essential constraint. Minor improvement could be adding why the filter requirement exists, but not necessary.

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 71% schema description coverage, the schema documents most parameters well. The description adds no new parameter information beyond listing suggested filter fields, which is already implicit in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches for providers using any combination of fields. It specifies the resource ('providers') and the action ('search'), distinguishing it from sibling tools like 'get_provider' which likely retrieves a single record.

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

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

The description provides clear context that the NPI Registry requires at least one filter, listing acceptable fields. While it does not explicitly mention when not to use this tool or name alternatives, the requirement gives practical usage guidance.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and not destructive. The description adds valuable behavioral details: uses BGE-base-en embeddings with cosine similarity over 500-char overlapping windows, a 200K char cap with truncation flag, and every passage includes character offsets for verification. This goes well beyond the annotations.

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

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

The description is concise (under 100 words), front-loaded with the core purpose, and every sentence adds value without repetition or fluff. It efficiently conveys the mechanism, limits, and usage guidance.

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

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

Given the rich annotations and schema, the description is fully adequate. It explains the embedding/chunking details, the document size cap, and the return format (passages with offsets and scores), even though there is no output schema. It also clarifies integration with ask_pipeworx_grounded.

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

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

Schema coverage is 100% with descriptions for all parameters. The tool description adds examples for the query parameter, notes the cap for text, and explains the limit meaning. This adds marginal value beyond the schema, justifying a slight upgrade from baseline 3.

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

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

The description clearly states the tool does semantic search inside a fetched record, with a specific verb and resource. It differentiates from sibling tools like search and ask_pipeworx_grounded by explaining its use case (searching inside a retrieved document) and pairing with the latter.

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 tells when to use this tool: when a record is too large to fit in the prompt, saving context. It also mentions pairing with ask_pipeworx_grounded. However, it does not provide explicit when-not-to-use or alternative scenarios, slightly reducing the score.

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

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

The description adds behavioral details beyond annotations: it requires OAuth, mentions SMS daily cap, phone verification, and webhook auto-disable after 10 failures. Annotations already mark it as not readOnly, not destructive, and idempotent; the description complements these without contradiction, providing useful operational 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 front-loaded with the main action and returns value, then covers requirements, types, and delivery details in a logical order. Although it is somewhat lengthy, every sentence contributes meaningful information, and the structure is clear and scannable.

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

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

Given the tool's complexity (3 parameters, nested objects, enum values, multiple delivery options) and no output schema, the description explains the return value, prerequisites, type options, and delivery constraints. It misses explicit mention of idempotency behavior but is otherwise complete for practical use.

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

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

With 100% schema description coverage, the description adds significant value by providing concrete JSON examples for each subscription type (e.g., sec_8k with item codes, polymarket_edge with topic) and detailed delivery channel behavior (e.g., webhook signing, SMS cap). This enriches the 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 creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It distinguishes itself from sibling tools like list_subscriptions (for listing) and unsubscribe (for removal) by specifying the creation action and resource type.

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

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

The description provides clear context: requires a Pipeworx OAuth account, differentiates delivery channels (feed always on, email/sms optional with constraints), and mentions alternative ways to pull alerts (recent_alerts or GET endpoint). It does not explicitly state when not to use it versus siblings, but the purpose and prerequisites are well covered.

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, non-destructive. Description adds behavioral context on return structure (category-bucketed examples with exact tool shapes) and that it draws from a live catalog.

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

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

Description includes many alternative phrasings and details but remains well-organized and front-loaded with purpose. Slightly verbose for maximum conciseness 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?

Complete description covering purpose, usage, return format, parameter semantics, and when to invoke. Given no output schema, it sufficiently explains what the tool returns.

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

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

Schema has full coverage for the optional 'topic' parameter. Description enhances with examples ('finance', 'pharma', 'betting') and clarifies that omitting gives a cross-category spread.

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

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

The description clearly states the tool's purpose as an onboarding entry point for new users, listing what Pipeworx can do and returning category-bucketed example questions. It distinguishes itself from siblings by being a meta-tool for learning.

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 to use it first when unfamiliar or to learn about meta-tools. Provides context like 'call with no arguments for full spread' and optional topic filtering, but does not directly contrast with every sibling.

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

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

The description discloses that the row is deactivated (not deleted) and that historical events remain via recent_alerts, which goes beyond the annotations (readOnlyHint=false, destructiveHint=false). This provides clear insight into the tool's non-destructive mutation behavior.

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

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

Three concise sentences with no unnecessary words. Every sentence provides essential information: action, ownership constraint, and effect on data. 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?

Given the tool has only one parameter, no output schema, and well-covered annotations, the description fully addresses what the agent needs: purpose, ownership, and behavioral impact (soft deactivation). No gaps remain.

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

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

The input schema has 100% coverage with a description for the 'id' parameter. The description only repeats 'by id' without adding additional semantics beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

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

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

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

The description explicitly states ownership enforcement: 'you can only cancel your own subscriptions.' This provides a clear precondition, though no explicit when-not-to-use or alternative tools are mentioned. The context is sufficient given the sibling 'subscribe.'

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, but the description adds substantial context: the dual execution paths (SEC vs grounded), the verdict taxonomy, and the crucial distinction between could_not_verify (didn't run) and unsupported (no source exists). This goes well beyond the safety hints and helps the agent interpret results correctly.

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

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

The description is front-loaded with trigger phrases and purpose, and every sentence carries useful information. However, it is quite long and the list of example phrases could be trimmed without losing meaning. Still, for a multi-path tool, the length is mostly justified.

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

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

For a tool with no output schema, the description fully covers what to expect: verdict types, actual value with citation, reasoning, and detailed explanations of could_not_verify and unsupported. It also explains the fallback routing, making it complete for an agent to decide on this 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% with detailed parameter descriptions (claim example, tolerance_pct range and default). The tool description adds a bit about percent-delta math and hallucination detection, but this is largely redundant with the schema. No significant new semantic value beyond what the schema already 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 opens with explicit trigger phrases and states the verb-resource pair: 'natural-language claim verification against authoritative sources.' It clearly distinguishes itself from siblings by noting it replaces 4–6 sequential calls and returns a verdict, unlike search or deep_research.

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

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

It explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also provides routing rules for company-financial vs. other claims and warns about could_not_verify semantics, giving clear when-to-use and when-to-be-cautious guidance.

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