Harvard Art

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. The description adds meaningful behavioral details: default model is free, Anthropic requires own key and direct payment, and the return structure (per-model score, confidence, signals, raw_response + combined view). 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 succinct with three sentences. It front-loads the primary action and key outputs, then adds parameter notes and use cases. 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?

Given the tool has 4 parameters (1 required), no output schema, and no enums, the description covers the entity, models, API key, and optional context. It explains the return format (per-model + combined view) and provides use cases. This is complete for a read-only inference 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 all parameters described. The description adds value beyond the schema by specifying the default model (Workers AI Llama-3.3-70b, free) and that _apiKey is required for Anthropic, which involves direct payment. This operational context enhances parameter meaning.

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

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

The description clearly states the tool's action: probe LLMs for knowledge about an entity and output visibility scores per model. It specifies the default model and the optional Anthropic probe, distinguishing it from siblings like scan_competitor_ai_presence by focusing on per-model scoring and combined view.

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

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

The description provides explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' While it does not explicitly state when not to use or name alternatives, the context is clear enough for appropriate selection.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavioral context beyond those: it routes to one of 5,706 tools across 1,493 verified sources, fills arguments automatically, returns structured answers with stable pipeworx:// citation URIs, makes one fast call, and works on every tier. This gives the agent an accurate model of what happens when invoked.

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

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

The description is longer than average, but nearly every sentence carries decision-relevant information: preferred status, supported domains, trigger phrases, examples, default-entry guidance, and upgrade paths. Some redundancy exists ('PREFER OVER WEB SEARCH' and 'even if web search could also answer it'), so it is not a perfect 5, but it is well front-loaded 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?

For a very broad, high-level query tool with no output schema, the description covers what it does, when to use it, when not to use it, what alternatives to step up to, what kinds of questions it accepts, and what the response includes (structured answer with stable citation URIs). Nothing essential for correct selection and invocation is missing.

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

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

Schema coverage is 100% and the schema documents the question parameter and its aliases, so baseline is 3. The description adds meaning by showing what kinds of natural-language inputs work ('current US unemployment rate', 'Apple's latest 10-K', '5-day forecast for Tokyo') and by noting the tool fills arguments itself, which clarifies that a single question string is sufficient.

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

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

The description states a specific purpose: route factual questions about real-world data to the right Pipeworx tool, and it distinguishes itself from web search and siblings by naming alternatives like ask_pipeworx_grounded and deep_research. It includes a concrete list of supported domains (SEC, FDA, FRED, USPTO, etc.) and example questions, so an agent can reliably tell what this tool is for.

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 guidance is explicit: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and 'Use whenever the user asks...' It also gives step-up conditions: use ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part queries. This is exemplary when-to-use-versus-alternatives guidance.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description reveals key behavioral traits: it is experimental, can change dynamically when a routing candidate is under test, currently has no active candidate and matches ask_pipeworx exactly, and is a fully working router with no fallback. This adds substantial context about version variability and operational status, going well beyond the structured fields.

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 composed of four focused sentences: identity, current status, usage guidance, and a clarifying statement that it is a full router. Each sentence earns its place and the most important fact (beta/identical router) is front-loaded. Slightly verbose but not wasteful.

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 modest complexity (one required question parameter with aliases, no output schema), the description is fully complete. It covers what the tool is, how it relates to ask_pipeworx, when to use it, its current operational state, and reassures that it is not a stub. No important operational or usage detail is missing.

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

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

Schema description coverage is 100%, with all six parameters (question plus five aliases) documented in the input schema. The description mentions 'same arguments' but adds no new semantics about the parameters themselves. Baseline of 3 is appropriate since the schema already fully documents each parameter.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, an identical universal router with the same 5,706 tools, arguments, and response shape. It explicitly differentiates from the stable sibling ask_pipeworx by noting the experimental candidate routing, making it easy for an agent to understand exactly what this tool does and how it differs.

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

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

The description provides explicit usage direction: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains that results are compared against the stable router, implying that for stable/production use, ask_pipeworx is the alternative. It doesn't explicitly state when not to use this tool, but the condition and context are clear.

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

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

Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior. The description adds substantial beyond-annotation context: exact success and refusal return shapes, the enumerated refusal reasons, the grounded-extraction guarantee, and the extra LLM call cost compared to ask_pipeworx. 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 but every sentence earns its place: purpose, mechanism, return contract, use cases, and cost comparison are all packed efficiently. The most important differentiator (grounded, hallucination-resistant) is front-loaded, and the alternative is named explicitly rather than left implicit.

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 compensates by spelling out the success response fields and the refusal contract with reason codes. It also covers cost trade-offs and usage boundaries, leaving an agent with all the decision-relevant information needed to call it correctly.

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

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

Schema description coverage is 100% and every alias is documented in the schema itself, so the description does not need to add parameter-level meaning. The description does not elaborate on parameter usage, but with full schema coverage the baseline of 3 is appropriate.

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

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

The description opens with a specific, differentiated purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly explains the mechanism (routing, fetching, then extracting only from tool results) and distinguishes itself from the sibling ask_pipeworx by emphasizing grounded extraction and explicit refusal behavior.

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

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

Provides explicit when-to-use guidance: high-stakes reads, quoted/cited/acted-on answers, and contexts where the agent must not invent facts. It also gives a concrete when-not-to-use directive: 'prefer ask_pipeworx for casual lookups,' with a cost rationale attached.

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

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

Adds extensive behavioral context beyond annotations: fan-out to multiple data sources, resolver contract, parent event extraction, news fallback, wide-spread warning, resolution-rule risk parsing. Consistent with annotations (readOnly, idempotent). No contradiction.

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

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

Description is long but well-structured with labeled sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.) and front-loaded headings. While verbose, the organization helps agents parse it. Could be trimmed slightly but still effective.

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

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

Despite no output schema, description comprehensively covers return structure (market, analysis, evidence), edge cases (low_confidence_match, market_closed_or_inactive), and additional mechanisms (parent_event, news fields, cancellation rule). Covers all plausible scenarios for a complex research tool.

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

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

Schema covers all parameters (100%). Description adds value by explaining market input formats, depth default ('Default thorough'), and include_raw effects (summary vs. full payload). Supplements schema with examples and use-case nuance.

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

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

Description explicitly states 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call' and specifies input types (slug, URL, question text). It distinguishes from siblings like polymarket_arbitrage by focusing on comprehensive research. Use cases are clearly listed.

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

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

Clearly defines when to use (should I bet on X, what does data say, is there edge) and provides guidance on checking market_match_confidence, parent_event, news fields. Mentions safety short-circuits for low-confidence and closed markets. Does not explicitly exclude use of alternative tools but scopes well.

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, non-destructive behavior. The description adds crucial behavioral details: it pulls LATEST 10-K data from SEC EDGAR/XBRL with correct off-calendar fiscal year handling, and for drugs it uses FAERS data. It also mentions sorted results and citation URIs. No contradiction with annotations.

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

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

The description is a single sentence that packs many examples and guidelines, but it remains logically structured with clear sections for examples, usage preference, data sources, and return value behavior. Could be slightly more concise without losing clarity.

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

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

Given the complexity of two entity types with different data sources, no output schema, and 2 required parameters, the description covers all essential aspects: data source (SEC EDGAR, FAERS), edge case (off-calendar fiscal years), sorting behavior, and citation URIs. It is complete for an agent to understand and invoke correctly.

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

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

Input schema has 100% description coverage with enum for type and array with min/max for values. The description adds meaning by providing examples (e.g., '["AAPL","MSFT"]' for companies) and clarifying what data each type retrieves. This goes beyond bare schema, but the schema itself is already quite descriptive.

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

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

The description explicitly states it performs side-by-side comparison of 2-5 entities (companies or drugs) using verbs like 'compare' and provides clear examples (e.g., 'X vs Y', 'rank these companies'). It distinguishes itself from siblings like entity_profile by covering multi-entity comparison.

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

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

The description gives explicit usage guidance: 'ALWAYS PREFER over sequential single-pack lookups' and specifies when to use each entity type (company pulls financial data, drug pulls adverse-event counts). It also clarifies that results are sorted by primary metric so queries like 'largest' are answered 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?

Even with readOnly/idempotent annotations, the description adds rich behavioral context: parallel facet decomposition, routing across 5,706 tools, findings packet contents, gaps[] for unanswered facets, contradictions[], citation_uri resolvability, semantic excerpting, hop fields, and expected latency ranges. This goes well beyond the annotations and informs the agent about failure modes and output richness.

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 long, but nearly every clause earns its place: auth, alternatives, scope, output shape, timing, and depth behavior are all included. It is not perfectly front-loaded or bulleted, and the account-requirement opening delays the core purpose, but the density is justified for a tool this complex.

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

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

With no output schema, the description thoroughly covers the return contract: verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, gaps[], contradictions[], hop, and citation_uri. It also covers auth, cost tiers, alternatives, latency, and edge-case behavior for current-news topics. An agent has enough to 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?

Schema coverage is 100%, so the schema already fully documents both 'question' and 'depth.' The description adds pricing context and latency expectations for depth levels, but mostly reinforces the schema's existing semantics rather than adding genuinely new parameter meaning. This meets the high-coverage baseline.

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

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

The description clearly identifies a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1493 STRUCTURED data sources... in ONE call.' It aggressively distinguishes itself from open-web search and from sibling ask_pipeworx by naming what it is not, making selection unambiguous.

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

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

Provides explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data,' and explicit when-not-to-use direction: 'For a single lookup use ask_pipeworx' and 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx.' It also covers the signed-in prerequisite and tells unsigned-in users to use ask_pipeworx instead.

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

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

Annotations declare readOnly and idempotent. Description adds that it returns top-N relevant tools with full schemas and examples, ready to call. No contradictions.

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

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

Single paragraph that efficiently conveys core purpose, usage context, and return behavior. Could be slightly more structured but contains no unnecessary words.

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

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

Given 6 parameters and no output schema, description covers main use case, return format, and examples. Annotations cover safety. Lacks details on pagination or error behavior but sufficient for selection.

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

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

Schema coverage is 100% (all 6 parameters described). Description only references the main query parameter indirectly and provides examples, but adds limited extra meaning beyond the schema.

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

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

Description clearly states action ('Find tools'), resource ('tools'), and scope ('by describing the data or task'). It lists specific data domains (SEC filings, FDA drugs, etc.) and distinguishes itself from sibling tools as a discovery mechanism.

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?

Description explicitly advises to call this tool FIRST when many tools are available and the option set is needed. It provides example queries but does not explicitly state when not to use it 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 indicate non-destructive, idempotent read. Description adds specifics: fans across SEC EDGAR, XBRL, USPTO, news, GLEIF; returns fields; notes patent feature soft-fails until May 2025. 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?

Long but well-structured: starts with examples, states purpose, details behavior. Each sentence adds value. Slightly verbose but effective.

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, so description covers return values comprehensively: CIK, filings (up to 5 with URIs), fundamentals sorted, patents status, news fallback, LEI. Fits complexity of multi-source profile 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 descriptions provide basic info. Description adds depth: explains type must be 'company', value formats (ticker or CIK), and that names are not supported, with examples. High coverage baseline 3, extra nuance justifies 4.

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

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

Clearly states it provides a full cross-source profile of a US public company in one call, with concrete example queries. Distinguishes from sibling tools like resolve_entity.

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

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

Explicitly instructs to prefer over chaining single-source lookups for holistic views. Tells when not to use (name only) and directs to resolve_entity as alternative.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, so description only adds that it targets 'previously stored' memory. Does not cover error handling for missing keys or irreversibility beyond what annotations imply.

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

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

Two sentences with no waste: first states purpose, second gives usage context. Perfectly concise.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential aspects. Minor nit: could mention that deletion is permanent, but not required.

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 description 'Memory key to delete', so description adds no extra meaning. Baseline 3 is appropriate.

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

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

Clear verb 'delete' and resource 'memory' with specific qualifier 'previously stored'. Distinguishes from siblings 'remember' (store) and 'recall' (retrieve).

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

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

Explicitly states when to use: stale context, task done, or clear sensitive data. Mentions pairing with related tools, though lacks explicit alternatives 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true for the first three and false for the last, indicating a safe, non-destructive, repeatable operation. The description goes beyond by detailing the process: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' This adds behavioral context without contradicting annotations.

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

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

The description is concise at two sentences plus a list of use cases. It is front-loaded with the main purpose, followed by process details and practical applications. No unnecessary words; every sentence adds value.

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

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

Despite lacking an output schema, the description fully explains the output ('single text blob ready to drop at site-root/llms.txt'). It covers the tool's functionality, process, and three distinct use cases. Given the tool's simplicity (2 parameters, no nested objects), the description is comprehensive and leaves no ambiguity.

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 input schema already documents both parameters. The description adds value by providing the default value (25) and maximum (50) for max_links, and clarifies that the URL is the 'site to summarize' with an example. This extra information helps the agent understand parameter constraints beyond the schema.

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

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

The description uses a specific verb ('generate'), identifies the resource ('llms.txt file'), and clearly defines the target ('any URL'). It explicitly distinguishes the tool's output format and purpose from sibling tools, making it easy for an AI agent to select this tool for the intended 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 lists concrete use cases (getting a client's site indexed, drafting for own project, auditing a competitor). Although it does not explicitly state when not to use the tool or name alternatives, the provided context signals and sibling list implicitly guide selection. The use-case enumeration is clear and actionable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; description adds return fields and default behavior (active only). Adds context beyond annotations.

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

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

Two efficiently written sentences: first states purpose and return fields, second provides usage guidance. No wasted words.

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

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

Complete for a simple tool: purpose, optional parameter behavior, return fields, and usage hint provided. No output schema but return fields are listed.

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 parameter, which is documented semantically in schema. Description does not add extra meaning beyond schema, so 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 clearly states it lists the caller's active subscriptions, with verb and resource. It distinguishes from siblings like 'subscribe' and 'unsubscribe'.

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

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

Provides explicit context for use: 'review what you're monitoring before adding more' and 'find an id to cancel'. No explicit exclusions but clear practical guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint as true and destructiveHint false, so the description doesn't need to repeat safety. It adds value by specifying the id origin and type, which is helpful 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, well-structured sentence that immediately conveys the tool's purpose and key constraints. No wasted words, and the core information is front-loaded.

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

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

For a simple read-only tool with clear annotations and parameter documentation, the description is complete. It tells the agent exactly what the tool does and what input it expects, leaving no gaps in understanding.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds that the id is numeric from search, which clarifies the parameter's expected format beyond the schema example. This provides useful 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?

The description explicitly states the verb 'Fetch full details', the resource 'Harvard Art Museums item', and the scope 'by id'. It clarifies that the id is numeric and comes from search, which helps differentiate from sibling tools like 'search'.

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

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

The description implies when to use it: when you have a numeric object id from search. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to distinguish from search.

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?

Given that all annotations are false, the description carries the full burden of behavioral disclosure. It reveals rate limiting ('5 per identifier per day'), the free-of-quota nature, the claim_token mechanism for later retrieval, and how the team processes feedback (daily digests). No contradictions with annotations exist.

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 information-dense. Every sentence contributes unique context (scope, exclusions, token flow, rate limit, quota). It is front-loaded with the primary purpose. Slightly verbose but justified by the tool's non-trivial behavior.

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 parameters and no output schema, the description fully covers behavior, return token semantics, limits, and scope. It even explains how to disambiguate Pipeworx tools from other MCP servers. 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 covers all four parameters with detailed descriptions (100% coverage). The description adds value beyond the schema by explaining the claim_token usage pattern and emphasizing that context should reference Pipeworx tools/packs. It does not repeat schema details verbatim.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' This clearly distinguishes the tool from all sibling tools, none of which handle feedback or issue reporting.

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

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

Explicit when-to-use and when-not-to-use guidance is provided. It lists concrete triggers (bug, feature request, data gap, praise) and clearly states that issues with tools from other MCP servers should be filed elsewhere. It also explains the claim_token follow-up flow, which is a usage pattern.

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, open-world. The description adds value by explaining data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). No contradictions.

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

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

Description is concise and well-structured: starts with the core purpose, then enumerates use cases, and ends with technical details (source, privacy, caching). Every sentence is informative without 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 tool with a single parameter and no output schema, the description covers input semantics, use cases, data provenance, privacy, and caching behavior. It fully enables an agent to decide whether and how to invoke the tool.

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

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

Schema coverage is 100% with enum descriptions. The description adds semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand,' helping the agent choose the appropriate window beyond just 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?

Clearly states the verb 'Returns' and specifies what is returned: top tools, top packs, and total call volume over a chosen window. The purpose is explicit and distinguishes this tool from siblings like discover_tools or search.

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

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

Lists three concrete use cases that help an agent decide when to invoke this tool. While it does not explicitly mention alternatives or when not to use, the use cases provide clear context. Slight deduction for missing exclusionary guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint (false). The description adds extensive behavioral context: internal logic (monotonicity violations, partition checks, semantic anchor, partition filter), response structure (opportunities array, partition_check object), and fill check details (realizable_edge_pp vs theoretical). 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 relatively long but well-structured. It front-loads the main purpose, then systematically explains modes and technical details. Every sentence adds value, though some sections (e.g., fill check) could be slightly condensed without losing clarity.

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

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

Despite lacking an output schema, the description thoroughly documents the response format: 'opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context)' and 'partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}'. It also covers edge cases (e.g., placeholders filtered, skipped_low_similarity) and the fill check behavior. The description is complete for the tool's complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the purpose of each parameter in depth: event slug format, topic description, and the behavior of each mode. It also provides usage examples and constraints (e.g., event recommended for specific market).

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

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

The description explicitly states the tool's purpose: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly differentiates from sibling tools by detailing distinct modes (trending scan, event, topic) and the specific methodology.

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

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

The description provides explicit guidance on when to use each mode: 'Call with NO args for a trending_scan... pass event for... or topic for...' It recommends event mode for specific markets and topic mode for cross-event scanning. It also advises against trading when fill check shows realizable_edge_pp <= 0 and references polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: caching behavior ('Cached 1h at the KV level keyed on all knobs'), response structure (by_segment with three segments, diagnostics), edge calculation (after slippage), and 24h move warning. 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 long but well-structured: high-level purpose first, then detailed segment breakdown, then output fields, then parameter knobs. Each sentence adds value, but could be slightly more concise. Still effective.

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

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

Without an output schema, the description thoroughly documents the response structure (by_segment, fed_candidates, _diagnostics), caching, and edge computation details. It covers all necessary aspects for an agent to understand what to expect and how to interpret 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?

All 9 parameters have schema descriptions (100% coverage), but the description adds meaning beyond the schema by explaining their interaction (e.g., min_partition_leg_kelly vs. min_kelly, slippage_pp default rationale, tradeable-edge knobs). This adds value beyond baseline.

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

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

The description clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This specifies the verb (scan/return) and resource (top Polymarket markets with discrepancies), and distinguishes from siblings like polymarket_arbitrage by focusing on Pipeworx data disagreement.

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 it is 'Built for "what should I bet on today"' and explains when to use it. However, it does not explicitly exclude alternatives or mention when not to use it, though the detail on Fed bets and caching provides context. Slightly missing explicit exclusion of sibling tools.

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive nature. The description adds significant behavioral details: snapshot-based data, computed fields (trend, decay), response structure, and limits (60-day TTL, daily closes). 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 informative but somewhat dense and verbose. It front-loads key concepts but could benefit from more structured formatting. Still, each sentence adds value.

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

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

No output schema, so description fully explains return values (tracked[], expired[], snapshot_dates[]) with field definitions. Also covers limitations and data source, making it complete for the tool's complexity.

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

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

Input schema covers both parameters with descriptions; the description reiterates defaults and adds clamping info ('max 30', 'clamp 2-30'), but schema already includes these. Little additional value beyond reinforcement.

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 provides 'edge persistence and decay telemetry' from daily snapshots, answering the question of edge longevity. It distinguishes itself from sibling tools like 'polymarket_edges' by focusing on the time-series aspect.

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

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

The description explains when to use this tool versus alternatives by contrasting fresh vs. aged edges, implying usage for assessing persistence. It lacks explicit when-not-to-use guidance but provides clear context.

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: walks order book ladder, returns verdict (clean|degraded|cannot_fill), warns about partial basket fills leading to unhedged positions. No contradictions. Minor lack of mention on rate limits or auth, but not expected.

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 lengthy but front-loaded with purpose and mode clarification. Every sentence adds value, though some repetition of schema defaults. Could be slightly more concise, but effective.

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 full schema coverage and no output schema, the description comprehensively explains return fields for both modes, including edge cases like thin legs and forced directional risk. Complete for a risk-check 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 descriptions for all 4 parameters. Description adds context beyond schema: defaults (size_usd=1000, side auto for basket), clamp range (10–1,000,000), and clarifies that market/event modes are mutually exclusive with REQUIRES one.

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

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

The description clearly states the tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth', distinguishes between single-market and basket modes, and lists specific return fields. This is specific and differentiates from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains why (theoretical overround not capturable, partial fills convert arb to directional position). Provides clear context with 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description complements these by explaining what the tool does not guarantee. It openly discloses matching limitations (keyword-based matching, non_equivalent_bet_shapes, unclassified legs excluded) and warns that pre-mapped topics are frequently untradeable. This is unusually transparent about internal behavior and failure modes without contradicting the annotations.

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

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

The description is information-dense but significantly longer than the calibration examples. Every sentence does provide useful operational detail, but the length makes it harder to scan; the most critical warnings (pre-mapped ≠ tradeable) are placed at the end rather than front-loaded. Still, it is structured with labeled sections and no wasted words.

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

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

Given zero output schema, the description carries full responsibility for explaining response fields, and it does so extensively: matched_spreads, top_spreads_pp with per-entry flags, skipped_unclassified, low_confidence_pairs, temporal_alignment, compatibility_warning/codes, and skipped counters. For a complex cross-venue tool with no structured output definition, this is as complete as an agent needs.

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

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

Schema coverage is 100%, so the schema already documents all three optional parameters. The description adds value by explaining the mode semantics (topic auto-fetches from shortcuts; explicit parameters override the topic-mapped side) and by giving examples of Kalshi ticker and Polymarket slug formats. There is no parameter-level semantic gap that the schema misses.

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

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

The description states a specific verb and resource: it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes itself from siblings by explicitly discussing both venues and comparing equivalent bet shapes. The two modes and their intended use (pre-mapped topics vs explicit tickers) make the purpose and selection unambiguous.

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

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

The description clearly enumerates when to use each mode: topic for 10 pre-mapped shortcuts, explicit kalshi_event_ticker + polymarket_event_slug for custom pairings. It warns that pre-mapped ≠ tradeable and that most topics return compatibility_warning today, effectively telling the agent when the tool will be less useful. It also names the safety fields to read even when matched pairs exist.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context: scoping to an identifier and the pairing with sibling tools. No contradictions with annotations.

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

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

The description is concise (2-3 sentences), front-loaded with the main action, and contains no redundant information. Every sentence serves a purpose.

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

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

Given the tool's simplicity (one optional parameter, no output schema, full annotation coverage), the description covers purpose, usage, parameter behavior, scope, and sibling relationships. It is complete and leaves no ambiguity for an AI agent.

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

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

Schema coverage is 100% for the single parameter. The description adds the semantic detail that omitting the key parameter lists all saved keys, which goes beyond the schema's description.

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

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

The description clearly states it retrieves a value saved via 'remember' or lists all keys when key is omitted. It specifies the verb 'retrieve' and the resource 'memory', and 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: to look up previously stored context without re-deriving it. It also mentions scoping by identifier and pairing with 'remember' and 'forget', providing explicit context for usage.

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

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

The description adds significant behavioral context beyond annotations: it explains that events are persisted, that mark_read affects subsequent calls, and that polling works. The annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent with the description, and no contradictions are present.

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

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

The description is a single, well-structured paragraph that front-loads the main purpose and immediately follows with key behaviors and usage examples. Every sentence adds value, and there is no redundancy.

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

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

Given the five parameters, no output schema, and no nested objects, the description covers all essential behaviors: what is returned, filtering options, state management via mark_read, and polling suitability. It is complete enough for an agent to use the tool correctly without additional 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%, so baseline is 3. The description adds value by explaining the effect of mark_read ('flag returned events read so the next call only shows newer ones') and integrating parameter usage into a coherent workflow (e.g., filtering by type and since). However, it does not provide additional details beyond the schema's descriptions for each parameter.

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

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

The description clearly states the tool 'pulls fired events from your subscription feed' and specifies the return fields (source, citation_uri, raw event payload). It is distinct from sibling tools like search or ask_pipeworx, 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?

The description provides context on when to use the tool, including filtering by type/since, using mark_read to manage read state, and polling. It even mentions an alternative REST endpoint for scripts. However, it does not explicitly list exclusions or compare with siblings, but sibling tools are sufficiently different.

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

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

Beyond annotations (readOnly, idempotent, etc.), the description details the fan-out to multiple sources (SEC, GDELT/GNews, USPTO), fallback logic, and the structured return format with citations. No contradictions.

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

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

The description is well-structured: begins with example queries, then explains sources, parameter details, and finally distinguishes from a sibling. 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?

Given the tool's complexity (multiple data sources, fallbacks, output format), the description covers all essential aspects: return structure (changes grouped by source, total count, URIs), parameter behavior, and edge cases like USPTO soft-fail. No output schema exists, so the description compensates fully.

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?

All three parameters are described with examples (e.g., 'since' accepts ISO date or relative shorthand like '7d', '30d'), and the description adds context beyond the schema, such as the meaning of 'value' accepting ticker or CIK.

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

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

The description clearly defines the tool as a change feed for a company over a recent time window, using example queries like 'What's new with X'. It distinguishes from sibling tool 'entity_profile' by specifying when to use the alternative.

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

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

The description provides explicit guidance on when to use this tool vs 'entity_profile', and explains the fallback behavior between GDELT and GNews. However, it does not list other alternative tools for similar queries.

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

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

Annotations include idempotentHint=true, which description supports by describing key-value storage. Adds important context beyond annotations: scoped by identifier, persistence for authenticated vs anonymous users (24 hours), and no destructive actions (destructiveHint=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?

Four sentences, all essential. Front-loaded with core purpose, then context, then complementary tools. No redundancy or 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?

Given no output schema and complete annotations, description fully covers all needed context: purpose, usage, behavior, parameters, and limits (24-hour retention). No gaps.

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

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

Schema covers 100% of parameters with descriptions. Description adds value by suggesting key naming conventions (e.g., 'subject_property', 'target_ticker') and clarifying value as 'any text' with examples, exceeding schema info.

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

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

Description explicitly states 'Save data the agent will need to reuse later' with specific verb and resource. It clearly distinguishes from siblings (recall, forget) by mentioning them as complementary tools.

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

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

Provides clear when-to-use guidance ('when you discover something worth carrying forward') and explicitly names alternatives: 'Pair with recall to retrieve later, forget to delete.'

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

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

The annotations declare read-only, idempotent, and non-destructive, and the description adds substantial behavior: cross-source identity spine, graceful degradation when GLEIF/OpenFIGI fails, explicit `unresolved` field, and internal cascade replacing 2-3 manual lookups. These go beyond the annotations and give the agent important execution expectations.

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

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

The description is long but well-structured with examples and SUPPORTED TYPES, and every sentence provides functional detail. It is front-loaded with user queries and avoids fluff, though it could be tightened without losing critical context.

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

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

For a complex two-parameter tool with no output schema, the description covers intended use, input formats, output components (identifiers, sources, unresolved), edge cases (degradation, non-US issuers), and a performance note. An agent has ample context 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 has 100% coverage, but the description enriches meaning: for `type`, it details each enum value's behavior; for `value`, it enumerates accepted formats (ticker, CIK, ISIN, name; brand/generic) and explains special ISIN-to-LEI mapping. This is far more informative than the schema alone.

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

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

The description clearly states the tool resolves a user-spoken name to canonical IDs required by other tools, with a specific verb ('resolve'), resource (names to identifiers), and supported types (company, drug). It distinguishes itself from siblings with 'Use FIRST whenever you have a name but need an ID' and detailed query examples.

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 instructs 'Use FIRST whenever you have a name but need an ID' and provides multiple query examples, which is strong when-to-use guidance. However, it does not name alternative tools or explicitly state when not to use it, so it doesn't earn a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, indicating safety. The description adds value by explaining the internal process (probing each entity with ai_visibility_check, ranking, scoring) and the output fields (score, confidence, signal density). This context goes beyond annotations.

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

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

The description is three sentences with no fluff. The first sentence states the core purpose, the second explains the process, and the third provides a concrete use case. Every sentence earns its place.

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

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

Given the 4-parameter schema (1 required) and no output schema, the description adequately explains the output (ranked list with score, confidence, signal density) and the purpose. It lacks information about rate limits or dependencies, but for a non-destructive read tool, it is fairly complete.

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

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

Schema coverage is 100%, so the schema already describes parameters well. The description adds the semantic detail that the first entity is treated as the 'subject' for narrative, which is not in the schema. This enhances understanding without contradicting the schema.

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

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

The description clearly states the tool's function: compare AI visibility across multiple entities side-by-side. It specifies the action (compare, probe, rank, surface), the resource (AI visibility), and distinguishes from siblings like 'ai_visibility_check' by emphasizing multiple-entity comparison.

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

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

The description provides a clear use case ('competitive AI-marketing audits') and an example question. It implies that for a single entity, one should use 'ai_visibility_check' instead, but does not explicitly state when not to use this tool. The guidance is strong but lacks explicit exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds critical behavioral details: partial degradation, bundlephobia's first measurement can take 5-30s, and sources_failed list. This goes beyond what annotations provide.

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

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

The description is somewhat lengthy but well-structured and front-loaded. Every sentence adds useful information. Could be slightly more concise, but given the complexity, it's appropriate.

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 return fields, failure behavior, and ecosystem scope. Covers purpose, usage, return values, and edge cases adequately.

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

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

Schema coverage is 100%, baseline 3. The description adds value by clarifying that package accepts scoped npm names and that version defaults to latest published. This enriches parameter understanding beyond the schema descriptions.

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

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

The description clearly states it is a composite check for npm packages covering safety, popularity, and size. It distinguishes from siblings by explicitly limiting to NPM ecosystem in v1 and referencing deps.dev:version for other ecosystems.

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

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

Provides explicit use cases ('is X safe / popular / small', 'what does adding lodash cost me') and specifies when not to use (for non-NPM ecosystems, use deps.dev:version directly).

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the return format and mentioning that an id can be passed to the 'object' tool, providing 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, well-structured sentence that front-loads the purpose and efficiently conveys key return details with no wasted words.

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

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

Given no output schema, the description adequately lists return fields (ids, titles, creators, dates, image links) and mentions the page/limit parameters. Missing details about empty results or error handling, but sufficient for a simple search 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 descriptions for all 4 parameters. The description adds no additional parameter-level meaning beyond what the schema provides, which is adequate.

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

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

The description uses a specific verb ('Search') and resource ('Harvard Art Museums collection'), and explicitly states the return fields (ids, titles, creators, dates, image links). This clearly distinguishes it from the sibling tool 'search_within'.

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

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

The description implies usage for keyword searches but does not provide guidance on when to use this tool versus alternatives like 'search_within' or what to avoid. No explicit exclusions or alternative tool references.

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

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

Beyond annotations (readOnly, idempotent, not destructive), the description discloses embedding model, window size, character cap with truncation/flagging, and that results include offsets and scores. 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?

Three sentences: purpose, usage guidance, technical details. Front-loaded and efficient; every sentence adds value without waste.

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

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

Despite no output schema, description explains return type (passages with offsets and scores) and covers limits and technical nuances. Thorough for a 3-parameter 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 meaningful examples for 'query' and clarifies usage for 'text' and 'limit'. With high coverage, baseline is 3; the extra value warrants a 4.

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

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

Title and description clearly state the tool performs semantic search inside a fetched record. It distinguishes from siblings like 'search' and 'ask_pipeworx' by specifying it's for records too large for the prompt.

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

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

Explicitly says when to use (when record is too big for prompt) and how it pairs with 'ask_pipeworx_grounded' for a two-step workflow. Provides clear context and alternatives.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds many behavioral details: requires specific account type, type-specific behaviors (e.g., 'sec_8k' items mapping), delivery channel constraints (phone verification, 10/day SMS cap, webhook signing and auto-disable after 10 failures), which go 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 well-structured: first sentence states purpose, then prerequisites, then type list with examples, then delivery options. It is lengthy but every sentence adds value. Could be slightly more concise, but not wasteful.

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, no output schema), the description covers type-specific parameter details, delivery channel options, idempotency, and account requirements. It mentions returning a subscription ID but doesn't fully describe the response shape. Still, it is fairly complete for the given 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% (baseline 3), but the description adds significant meaning: for 'type' it lists enum values with example mappings (e.g., items for sec_8k), for 'params' it gives concrete JSON examples per type, and for 'delivery' it explains each channel's constraints and behavior (e.g., webhook HMAC signing and retry mechanism). This greatly 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 creates a proactive monitoring subscription to a live-data event stream and returns the new subscription ID. It distinguishes itself from sibling tools like list_subscriptions and unsubscribe by being the creation 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 specifies when to use (live-data monitoring), the supported types (with examples), delivery channels, and a prerequisite (Pipeworx OAuth account). It lacks explicit 'when not to use' or direct alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds meaningful context about the output (category-bucketed example questions with exact tool+args) and that it draws from the live catalog. 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 front-loaded with natural language phrases and effectively organized. It is slightly long but each sentence adds value, making it clear and 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?

The tool is simple with one optional parameter and no output schema. The description fully explains its purpose, output format, and usage scenarios, making it complete for an onboarding tool.

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

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

Schema coverage is 100% and the description largely repeats the schema info for the topic parameter. It adds context about when to omit or use a topic, but no new parameter semantics 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 clearly states the tool is an onboarding entry point for new users, returning category-bucketed example questions. It distinguishes itself from siblings like ask_pipeworx and entity_profile by specifying it should be used first to learn what Pipeworx can do.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains how to call with or without a topic. It mentions alternatives like meta-tools but does not explicitly state when not to use it.

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

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

Annotations indicate this is a write operation (readOnlyHint: false) with no destruction (destructiveHint: false). The description adds value by explaining the row is deactivated (not deleted) and that historical events remain, confirming and enriching the annotation hints.

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

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

The description is two sentences long, front-loads the primary action, and every word contributes meaning. No redundancy or 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?

Without an output schema, the description covers ownership, deactivation semantics, and historical availability. For a single-parameter tool, this is sufficient for an agent to understand consequences.

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 one parameter 'id' clearly described. The description restates 'by id' but adds no additional semantic meaning beyond the schema. 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 'Cancel a subscription by id,' specifying the action (cancel) and resource (subscription). It effectively distinguishes the tool from siblings like 'subscribe' (which creates) and 'list_subscriptions' (which lists).

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: ownership enforcement ('you can only cancel your own subscriptions') and behavioral nuance (deactivation vs. deletion). While it doesn't explicitly state when not to use, the constraints are well-articulated.

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 safe behaviors, and the description adds substantial context beyond that: the full verdict set, the two verification pathways (SEC EDGAR + XBRL fast path vs grounded pipeline), the use of verbatim evidence with citations, and a critical distinction between could_not_verify (check did not happen) and unsupported (no source found). 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 but well-structured: user-facing examples up front, then a clear definition, then execution paths, verdict list, and critical caveats. Every sentence adds operational value without repeating schema fields or annotation hints. It is concise given the complexity of the 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?

Since there is no output schema, the description compensates by detailing the return values (verdict enum), the citation format, and error handling (verification_error). It explains both the financial and general grounded paths, making the tool fully usable without additional context. No gaps in the provided 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?

Both parameters (claim and tolerance_pct) are fully documented in the input schema with 100% coverage, including examples, valid range, behavior, and default values. The description itself adds no additional parameter-level detail beyond what the schema already provides, so the 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?

Description opens with natural-language triggers ('confirm or refute', 'true or false') and states 'natural-language claim verification against authoritative sources'. It clearly identifies the tool's purpose with a specific verb (verify) and resource (claims), and distinguishes it from sibling tools by describing the two execution paths and noting it replaces 4–6 sequential calls.

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

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

Explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct.' Differentiates company-financial claims from all other factual claims, providing routing guidance, and gives important usage caveats around the could_not_verify verdict, ensuring agents do not misinterpret it as evidence. This is strong, actionable guidance.

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