Ecuador Procurement

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds beyond annotations: discloses that passing _apiKey probes Anthropic with BYO key (cost implication), default model is free, and returns per-model data. 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 4 sentences, front-loaded with main function. Each sentence adds unique value: first defines action, second covers optional parameters, third explains return format, fourth suggests use cases. No fluff.

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

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

Despite no output schema, description explicitly states return structure: 'Returns per-model {score, confidence, signals, raw_response} + a combined view.' It covers all key aspects needed for an agent to understand inputs and outputs.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds value by explaining default model, that Anthropic requires key, and that context helps disambiguate. These details go beyond the schema's parameter descriptions.

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

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

Description clearly states 'Probe one or more LLMs for what they know about a business/brand/product/topic and score visibility (0-100) per model.' This is a specific verb and resource. It distinguishes from siblings like scan_competitor_ai_presence by focusing on scoring visibility per model.

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 lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It provides context for when to use. However, it does not explicitly mention when not to use or compare to alternative sibling tools like ask_pipeworx or deep_research.

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

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

Annotations already declare readOnlyHint/openWorldHint/idempotentHint. The description adds context about routing across 5,566 tools, returning stable citation URIs, being fast, and working on every tier. It also explains that it handles breaking news and live data, which complements the openWorldHint. No contradiction.

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

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

The description is long but every sentence serves a purpose: primary instruction, domain scope, examples, alternatives, and tier/performance notes. It is front-loaded with the most critical directive and remains 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?

Covers the tool's domain coverage, usage triggers, output characteristics (structured answers with citation URIs), alternatives, and operational details (one fast call, works on all tiers). For a default entry-point tool, this is comprehensive.

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 documented as aliases for 'question'. The description provides rich examples but does not add further parameter-level semantics beyond what the schema already states. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as the default entry point for factual questions about real-world data, with specific verbs like 'routes', 'fills arguments', and 'returns structured answers with citations'. It distinguishes itself from siblings by explicitly naming ask_pipeworx_grounded and deep_research as step-up alternatives.

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 'PREFER OVER WEB SEARCH' guidance, enumerates domains, lists trigger phrases, gives examples, and states when to step up to alternative tools. It also clarifies that ask_pipeworx works on every tier as a one-call default, leaving no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds useful behavioral context: it is a beta with experimental routing, currently matches the stable router, and is a full working router (not a fallback). This adds value beyond the annotations without contradicting them.

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

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

The description is concise (three sentences), front-loaded with purpose, and every sentence adds value (status, usage, clarification). No wasted words or redundant information.

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

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

The description covers the tool's beta nature, current status, usage equivalence to ask_pipeworx, and explicitly states it is a full working router. It references 'same response shape' as ask_pipeworx, which is sufficient given the agent likely knows the stable tool. No output schema exists, but the reference fills the gap 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?

The schema has 100% coverage describing the question parameter and its aliases. The description does not add any additional parameter semantics beyond what the schema already provides. With full schema coverage, the baseline is 3, and the description provides no extra insight, so it stays at 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 this is a beta version of ask_pipeworx, a universal router, and explicitly distinguishes it from the stable ask_pipeworx by noting it has candidate routing improvements and is currently identical. The verb 'ask' plus the router context makes the purpose unambiguous.

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

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

The description gives explicit usage guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It implies when to use (experimental) and references the stable alternative through comparison. It could be stronger by explicitly stating not to use for production/stable workflows, but it provides clear context and an 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 declare readOnly/openWorld/idempotent, but the description adds substantial behavioral details: returns a structured object with evidence, confidence, source, and refusal reasons; explicitly lists all refusal_reason enum values; and discloses the extra LLM call cost. This goes well beyond the annotations and sets clear expectations for failure modes.

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

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

The description is longer than average, but every sentence earns its place: purpose, routing behavior, extraction guarantee, return format, refusal behavior, usage cases, and cost trade-off. It is front-loaded with the most critical information and well-structured, though slightly dense.

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

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

The description is exceptionally complete for a tool with no output schema. It explains the return shape, all refusal reason values, the extra LLM call cost, and the distinction from the sibling tool. Given the complexity and high-stakes use case, nothing essential is missing.

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

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

Schema coverage is 100% with all parameters documented as aliases for the 'question' parameter. The description does not add any parameter-specific semantics beyond what the schema already provides, so the baseline score of 3 applies. It does clarify that routing fills arguments internally, but this is not about user-facing parameters.

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

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

The description clearly identifies this as a 'hallucination-resistant answer mode' and explicitly contrasts it with ask_pipeworx, explaining that it extracts answers only from tool results. The verb 'EXTRACTS' and the resource scope make the purpose unmistakable and distinct from siblings.

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

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

The description gives explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on' and contrasts with 'prefer ask_pipeworx for casual lookups.' It also names the alternative (ask_pipeworx) and specifies the extra cost trade-off.

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 extensively discloses behavioral traits beyond annotations: it details the resolution process, fan-out patterns, response shapes, safety mechanisms (low-confidence blocking, closed market handling, wide-spread warnings), and cancellation rule parsing. Annotations only indicate read-only, open-world, idempotent, and non-destructive, but the description adds rich behavioral context.

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

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

The description is very long and packed with details. While every piece of information seems relevant, the length may hinder quick scanning. The main purpose is front-loaded, but the extensive enumeration of classifiers, fan-out examples, response shapes, and edge cases makes it dense. A more structured approach (e.g., bullet points) could improve conciseness.

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

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

Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers input formats, resolution logic, fan-out examples, response structures, safety checks, cancellation rules, and error conditions. An agent would have sufficient information to invoke and interpret results correctly.

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

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

The input schema already describes all three parameters with 100% coverage. The description adds value by explaining the effect of 'depth', 'include_raw', and the accepted formats for 'market'. It provides examples and clarifies default behaviors (e.g., 'thorough' default for depth). This is helpful but not groundbreaking beyond the schema.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input formats (slug, URL, question text) and the overall workflow including resolution, classification, and fan-out. It distinguishes itself by listing specific use cases and classifiers, 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 explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also gives examples of when the tool blocks (low-confidence matches, closed markets, wide spreads). However, it does not explicitly compare with sibling tools like polymarket_edges or polymarket_arbitrage, which would strengthen guidance.

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

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

Beyond annotations (readOnly, idempotent, etc.), the description adds that it makes one parallel call, handles off-calendar fiscal years, sorts by primary metric, and returns paired data with citation URIs. No contradictions with annotations.

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

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

Single dense paragraph well-organized from triggers to purpose to details. Could benefit from slight structural breaks (e.g., bullet points for type options) but every sentence adds value.

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

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

Covers entity types, data sources, sorting behavior, and output format (paired data + citation URIs). Missing output schema is partly compensated by description. Could mention response size limits or pagination, but adequate for tool complexity.

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

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

Schema coverage is 100% with descriptions for both parameters, but the description adds crucial context: enum values are elaborated (what data each type pulls), values parameter gets entity-specific examples (tickers vs drug names), and constraints (min/max items). This significantly enhances agent understanding beyond schema.

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

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

Description starts with natural language triggers, then explicitly states it performs side-by-side comparison of 2-5 entities in one parallel call, with specific data types for company vs drug. It differentiates from sequential lookups and sibling tools like entity_profile by emphasizing parallelism and multi-entity focus.

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 gives when-to-use examples (compare, vs, rank, head-to-head) and states 'ALWAYS PREFER over sequential single-pack lookups'. It also notes efficiency gains (replaces 8-15 lookups), providing strong usage guidance.

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

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

Even with readOnly, idempotent, and non-destructive annotations, the description adds substantial behavioral context: it discloses account/pricing requirements (free vs paid plan for depth:'thorough'), expected latency (15-60s, up to ~90s for thorough), the gap[] behavior (explicitly never invented), findings packet shape (verbatim evidence + confidence + source + fetched_at + citation), contradiction detection for standard/thorough, hop fields, citation_uri resolvability, and semantic excerpting. No contradiction with annotations.

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

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

The description is long, but every sentence adds distinct value and is front-loaded with the most critical operational constraint (account required, signup URL, paid tier for thorough). It uses caps and precise numbers to compress information. However, it is dense enough that it could be slightly restructured for easier scanning, and the length is on the edge of what an agent can quickly parse; hence 4 rather than 5.

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

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

There is no output schema, but the description fully defines the return packet: verbatim evidence, confidence, source, fetched_at, stable pipeworx:// citation per finding, gaps[] for unanswered facets, contradictions[] for disagreements, hop field, and citation_uri only when the source emits a fetchable record. It also covers latency, pricing, and depth-specific behavior, leaving no major ambiguity for an agent to invoke or interpret the result.

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 both parameters with 100% coverage, so the baseline is 3. However, the description adds significant meaning beyond the schema: it explains the depth parameter's behavioral differences (quick=3 facets single-hop, standard=gap recovery + contradictions, thorough=6 facets + iterative lead-chasing) and the latency implications, and it clarifies that the question parameter can be broad/multi-part because decomposition is the point. This goes well beyond the schema's dry definitions.

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

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

The description opens with a very specific verb+resource+scope: it performs grounded multi-source research across 1,462 structured data sources, decomposes the question into facets, and routes them in parallel to 5,566 tools, returning a findings packet with verbatim evidence, confidence, source, and citations. It explicitly says this is NOT open-web search and gives concrete example use cases, clearly distinguishing it from sibling tools like ask_pipeworx.

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

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

The description provides explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data' and gives examples. It also names alternatives and exclusions: 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx', and even covers the signed-out case ('If you are not signed in, use ask_pipeworx instead'). This is exemplary usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context: it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)' and notes that results are 'ready to call directly, no second schema lookup needed.' This exceeds 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 three sentences, front-loaded with the primary purpose ('Find tools by describing the data or task.'). Each sentence is efficient and informative, covering usage context, output features, and a call-to-action ('Call this FIRST...'). No redundant or filler content.

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

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

Given the complexity (discovery tool with multiple aliases, broad domain coverage), the description, schema with examples, and annotations together provide complete context. The description explains the output format ('names, descriptions, and full input schemas') without needing an output schema. It is fully sufficient for an AI to decide when and how to invoke this tool.

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

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

The input schema has 100% parameter description coverage, so the baseline is 3. The description adds meaning by listing example domains (SEC filings, financials, FDA drugs, etc.) that clarify appropriate query topics. It also notes that 'query' accepts multiple aliases, which helps the agent understand flexibility. The examples in the schema further supplement this.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It uses specific verbs ('discover') and identifies the resource ('tools'). It distinguishes from sibling tools by emphasizing this is for browsing/exploration before direct tool 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?

The description explicitly states when to use: 'Use when you need to browse, search, look up, or discover what tools exist for...' and 'Call this FIRST when you have many tools available and want to see the option set.' It provides clear context but does not explicitly exclude other scenarios, such as when the exact tool is already known.

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, so the description does not need to reiterate safety. It adds value by detailing the returned data fields and source, but no new behavioral traits are revealed 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 efficient sentences: first sentence states purpose and source, second lists return fields. No fluff, front-loaded, 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?

With one parameter and no output schema, the description fully explains input (OCID with source) and output (all returned data categories). Context about SERCOP data is sufficient for a single-record retrieval 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?

The schema already describes the ocid parameter with an example. The description goes further by explaining where to obtain the ocid (from ecuador_search_tenders) and clarifying the format, adding meaning beyond the schema.

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

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

The description clearly states the tool gets 'full detail for a single Ecuador procurement process' by OCID, specifies the data source (SERCOP / Compras Públicas), and lists return fields. It distinguishes from sibling ecuador_search_tenders, which returns a list.

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 'Get the ocid from ecuador_search_tenders', providing clear guidance on when to use this tool (after obtaining an OCID). It implies the alternative use of ecuador_search_tenders for lists, though not explicitly stating when not to use this tool.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive hints. The description adds behavioral traits beyond annotations: it indicates pagination, that the API is live, and that results are shaped from it. 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?

Two sentences packed with essential information: tool purpose, preferred use cases, output details, and relationship to sibling tool. No redundancy, front-loaded with key facts.

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

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

No output schema, but description fully explains returned fields (ocid, buyer, supplier, amount, etc.) and pagination. The tool's complexity (searching government procurement) is well-covered, and the relationship to ecuador_get_record is clear.

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 each parameter already described (page defaults to 1, year defaults to current, query is free-text). The description adds no new meaning to the parameters themselves, only describes the output structure. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches Ecuador government procurement processes from SERCOP/Compras Públicas OCDS data, listing specific process types and explicitly preferring it over web search for certain queries. It also distinguishes the tool by mentioning the ocid field for detail retrieval via ecuador_get_record.

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

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

The description explicitly says 'PREFER OVER WEB SEARCH' and gives concrete examples like 'who won a contract in Ecuador'. It also tells the agent to use ecuador_get_record for full detail, providing clear when-to-use and when-not-to-use guidance. The sibling list confirms the 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 declare read-only, idempotent, and non-destructive. The description adds context: parallel fan-out across sources, specific data returned, fallback mechanisms (GDELT→GNews), and soft-fail for patents. 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?

Front-loaded with examples and purpose, then detailed output list. Slightly verbose but every sentence adds value. Could be 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?

No output schema exists, but the description comprehensively details return fields (cik, company_name, recent_filings with URIs, fundamentals, patents, news, LEI). Limitations and fallbacks are stated. Complete for a 2-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% with descriptions. The description adds meaning: explains value can be ticker or CIK, states names not supported, and gives examples. Elevates 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 uses concrete example queries and a clear verb+resource statement: 'full cross-source profile of a US public company in ONE parallel call.' It distinguishes from sibling tools like resolve_entity and compare_entities by specifying the scope and method.

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

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

Explicitly states 'ALWAYS PREFER over chaining single-pack ... lookups when the user asks for a holistic view,' and provides clear when-not-to-use guidance: 'names not supported (use resolve_entity first).' Also mentions the patent source limitation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description adds little beyond stating the deletion action. It does not disclose what happens if the key doesn’t exist or any side effects, but annotations cover the key behavioral aspects adequately.

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 with no wasted words. The first sentence states the core purpose, the second provides usage guidance. It is well front-loaded and efficient.

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

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

Given the simple tool with one parameter, full schema coverage, and no output schema, the description completely covers purpose and usage. Annotations add behavioral context, and siblings are mentioned. No gaps remain for an agent to understand 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%, so the baseline is 3. The description does not add any new information about the parameter beyond what the schema already provides ('Memory key to delete'). No additional semantics or format hints are given.

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

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

The description clearly states the action 'Delete a previously stored memory by key', identifying the resource (memory) and the identifier (key). It distinguishes itself from siblings 'remember' and 'recall' by suggesting pairing, making the purpose unambiguous.

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

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

The description provides explicit usage scenarios: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also mentions pairing with related tools, though it does not explicitly list alternatives for 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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds concrete behavioral details: fetches the page, extracts title/description/key links, and emits standard markdown format. It does not contradict annotations; bar is lower due to coverage.

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

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

The description is two sentences—the first clearly states the action and purpose, the second lists use cases. No wasted words; every sentence earns its place. Front-loaded with the primary function.

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 (2 parameters, no output schema), the description provides sufficient context: it explains the output format (single text blob ready for site-root/llms.txt) and the extraction process. Omitted details like error handling or rate limits are not critical for this safe, idempotent tool.

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

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

Schema description coverage is 100% for both parameters (url and max_links). The description does not add extra meaning beyond what's in the schema, such as default values or constraints, so baseline score of 3 is appropriate.

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

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

Description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb 'Generate' and the resource 'llms.txt file'. It also provides three concrete use cases (client indexing, own project, competitor audit), distinguishing it from sibling tools like 'scan_competitor_ai_presence'.

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 specific use cases (indexing a client's site, drafting for own project, auditing competitor) but does not explicitly state when not to use it or mention alternative tools. However, the context is clear enough for an AI agent to infer appropriate 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?

Annotations already indicate readOnly and idempotent; description adds that active subscriptions are listed by default and the optional include_inactive parameter, plus return fields. No contradictions.

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

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

Two sentences: first states purpose and output, second gives 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?

No output schema but description lists return fields; explains the single parameter. Completely sufficient for a simple list 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 schema already describes the parameter. Description adds no additional meaning beyond the schema.

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

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

The description specifies 'List the caller's active subscriptions' which is a specific verb+resource. It distinguishes from siblings like subscribe/unsubscribe by focusing on listing and reviewing.

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: 'review what you're monitoring before adding more or to find an id to cancel.' Provides clear context and excludes inappropriate uses.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false, etc.), so the description carries the burden. It discloses important behaviors: filing without an account returns a claim_token which can be used later to read the status, rate-limiting to 5 per identifier per day, the feedback is free and doesn't count against quota, and the team reads digests daily. These go far beyond what annotations provide.

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

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

Although the description is longer than typical, every sentence earns its place. It is front-loaded with the core purpose, then covers when-to-use, exclusions, claim_token usage, and rate limits. The structure is logical and no information is redundant with the schema. It is appropriately sized for the complexity of the tool's feedback workflow.

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

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

Given the tool's complexity (4 parameters, nested objects, no output schema), the description is remarkably complete. It covers all essential aspects: what to report, what not to do, how to follow up via claim_token, rate limiting, and quota impact. It is sufficient for an agent to know exactly when 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%, so baseline is 3. The description adds extra meaning beyond the schema: it explains the claim_token workflow ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and instructs users to 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt,' which adds context for the message parameter. This lifts it above baseline.

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

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

The description immediately states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly specifies the resource (Pipeworx feedback) and the action (sending feedback). It also differentiates itself from siblings like ask_pipeworx by focusing on reporting issues with the tool catalog itself.

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

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

The description provides explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a clear exclusion: 'ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead.' This is exemplary usage guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context: 'Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.' This discloses data source and caching behavior beyond annotations, though the bar is already lowered by the rich annotations.

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

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

The description is four sentences, well-structured with bullet-point use cases. It front-loads the main purpose and every sentence adds value: main action, three use cases, and behavioral context. 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 one parameter fully covered by schema, rich annotations, and no output schema, the description is complete. It explains what is returned (top tools, packs, call volume), the data source, caching, and use cases. Nothing essential is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the use-case distinction between windows ('current events' vs 'steady-state demand'), which goes beyond the schema's description of window. It also integrates with the three use cases, enhancing semantic understanding.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume over a recent window.' It uses specific verbs ('returns') and resource nouns ('tools', 'packs', 'call volume'), distinguishing it from siblings like 'discover_tools' or 'ask_pipeworx' which serve different purposes.

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

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

The description explicitly lists three use cases: discovering hot data sources, confirming canonical choice, and aligning with agent needs. It also contrasts window options ('shorter windows surface what's hot right now; longer windows show steady-state demand'), providing clear guidance on when to use each.

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, not destructive. The description adds extensive behavioral detail: monotonicity checks, partition sums, Jaccard similarity filter, placeholder filter, fill check against CLOB depth, and response structure. It also warns when not to trade (realizable_edge_pp ≤ 0). Highly transparent.

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

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

The description is lengthy but well-structured: overall purpose, mode explanations, technical details (Jaccard, partition filter, fill check), response format. Every sentence adds value for a complex tool. Some redundancy (e.g., partition_check explanation repeated) but overall efficient.

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

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

Despite no output schema, the description fully details the response structure (opportunities[], partition_check object) and explains edge cases (skipped_low_similarity, placeholders_filtered, thin_legs[]). For a complex arbitrage tool, it provides all necessary context for correct invocation and interpretation.

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

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

Schema descriptions cover 100% of parameters. The description significantly adds meaning: explains event mode requires a slug like 'fed-decision-may-2026', topic mode works with seed questions, and details the internal behavior (partition_check, semantic anchor, fill check). This far exceeds the schema's minimal descriptions.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between event, topic, and no-arg modes. However, it does not explicitly differentiate from sibling tools like polymarket_edges or polymarket_fill_risk, so it's a 4 rather than 5.

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

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

Provides explicit guidance on when to use each mode: no args for trending scan, event for a specific market, topic for cross-event scanning. Explains that cross-event mode catches patterns single-event misses. This 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?

The description extensively discloses behavioral traits: caching (1h at KV level), model family details, response structure with diagnostics, filter behaviors, and limitations (Fed bet exclusion). This goes far beyond the annotations, which already indicate read-only and idempotent hints.

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

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

The description is thorough but verbose, running nearly 500 words. While well-organized with clear sections, it could be more concise. Every sentence adds value, but length impacts readability.

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 (9 parameters, no output schema), the description is remarkably complete. It explains the entire response structure, model families, edge fields, diagnostics, filter behaviors, and even tool limitations. No output schema means the description must carry the full burden, and it does.

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 tradeable-edge knobs, giving default values, and providing usage guidance (e.g., adjusting slippage). This extra context elevates the score.

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 scans Polymarket markets for edges where Pipeworx data disagrees with market price, with a specific verb+resource. However, it does not explicitly distinguish this tool from siblings like polymarket_arbitrage or polymarket_edge_tracker, which prevents a top score.

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 the tool's purpose ('what should I bet on today') and provides filtering knobs, but it lacks explicit guidance on when to use this tool versus alternatives. No when-not or exclusion criteria are given beyond the Fed bet note.

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

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

The description adds extensive behavioral detail beyond annotations: explains the data source (daily snapshots), TTL, snapshot gaps, decay calculation (from daily closes, not intraday), and the full response structure including tracked, expired, and snapshot_dates 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 thorough and front-loaded with the core question. While it is lengthy, every sentence adds value and no information is redundant. Slightly more structured formatting could improve readability, but it's well-organized.

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

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

Given no output schema, the description fully explains the response structure (tracked, expired, snapshot_dates) and their fields (e.g., edge_pp_net, trend, decay_pp_per_day). It also covers limits (TTL, start date) and provides necessary caveats (decay not intraday).

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 description adds context to the parameters: 'days' is explained as lookback with default 14 and clamp 2-30, and 'window' is described as the snapshot family with examples. Since schema coverage is 100%, the description adds extra value.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' and answers the specific question about edge duration and trend. It distinguishes itself from sibling tools like polymarket_edges by focusing on historical time-series analysis.

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 by contrasting fresh vs. old edges, and what the tool offers over current snapshots. While it doesn't explicitly state 'when not to use', the context is clear and sufficient for an agent to decide.

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

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

Annotations (readOnlyHint, idempotentHint, openWorldHint) already indicate a safe, read-only operation. The description adds behavioral details beyond annotations: it walks the ladder, returns a verdict (clean|degraded|cannot_fill), and warns about thin legs and forced directional risk. No contradiction with annotations.

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

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

The description is somewhat long but well-structured with bold headings for modes and a clear ordering of information. Every sentence adds value. Minor conciseness improvements could be made, but the complexity of dual modes justifies the length.

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

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

Despite lacking an output schema, the description explicitly enumerates all return fields for both modes, covering edge cases like thin_legs and forced_directional_risk. It compensates fully for missing structured output information, making the tool's behavior completely understandable.

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

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

Schema coverage is 100%, but the description adds significant semantics: it explains the dual-mode interpretation of `market` vs `event`, `side` defaults per mode, and `size_usd` interpretation (spend vs target proceeds for single-market; settlement notional for basket). This adds value beyond the schema definitions.

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

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

The description clearly states the tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes, listing specific return fields (e.g., top_of_book, vwap_fill_price, slippage_pp, verdict). It explicitly differentiates from siblings by advising 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'.

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

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

The description provides explicit when-to-use guidance: 'before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains the rationale (theoretical overround not capturable, partial basket fills cause directional risk). It also states requirements: 'REQUIRES one of `market` or `event`'. This 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?

The description thoroughly discloses behavior beyond annotations: it explains the two modes, response structure (leg-by-leg prices, spread array, top_spreads_pp), safety fields (compatibility_warning, temporal_alignment), and counters for dropped comparisons. No contradiction with annotations (readOnly, idempotent, non-destructive) is 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 verbose but well-structured with line breaks and clear sections. It front-loads the core purpose and then details modes, response fields, and warnings. While some details could be reserved for output documentation, the length is justified by tool complexity.

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

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

Given the lack of an output schema, the description provides comprehensive information about the response fields, edge cases, and warnings. It covers all necessary aspects for an agent to understand and use the tool correctly, despite 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?

The description adds substantial meaning beyond the schema: it explains the topic shortcut list, the overriding behavior of explicit tickers, and how the tool selects events. Schema coverage is 100%, and the description enriches understanding of parameter usage and response 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 clearly states the tool computes the cross-venue spread between Kalshi and Polymarket for the same event. It distinguishes from siblings like polymarket_arbitrage by focusing on cross-venue comparison. The two modes (topic shortcuts and explicit tickers) are explicitly outlined.

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 each mode and warns that most pre-mapped topics return compatibility warnings, implying they may not yield tradeable spreads. However, it does not explicitly compare to sibling tools (e.g., when to use this vs. polymarket_arbitrage), leaving some inferential burden.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds scoping to user identifier and the listing behavior, which goes beyond annotations without contradiction.

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

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

Three short sentences, no redundancy. Front-loaded with core action, followed by use cases and relationship to siblings. Every sentence adds value.

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

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

For a simple recall tool with 1 parameter and no output schema, the description covers purpose, usage, and scope. Could mention return format but not essential given simplicity.

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

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

The parameter 'key' is fully described in the schema (100% coverage), but the description adds the context of omitting it to list all keys, which is not in the schema description.

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

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

The description clearly states the tool retrieves a value by key or lists all keys, distinguishing it from sibling tools like remember and forget. The verb 'retrieve' and resource 'values previously saved' are specific.

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 use cases (look up ticker, address, notes) and pairs with remember/forget, but does not explicitly state when not to use it. However, the context is sufficient for an agent.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral details like mark_read affecting subsequent calls and the return payload structure.

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

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

The description is front-loaded with purpose and each sentence adds value. It is concise but packs necessary information; could be slightly more structured but not excessively long.

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

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

Given no output schema, the description covers return payload fields, filtering, mark_read behavior, and alternative endpoint. It is fairly complete for a read-only list 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 basic descriptions. The description adds examples and behavioral context for type, since, and mark_read, but does not cover all parameters (e.g., limit, unread_only) in the text.

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

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

The description clearly states it pulls fired events from a subscription feed, specifying the resource and verb. However, it does not explicitly distinguish this from sibling tools like list_subscriptions or subscribe.

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

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

It provides usage context such as filtering options and polling suitability, but does not explicitly state when not to use this tool or what alternatives exist among siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral details beyond annotations: the tool fans out to multiple sources, uses GDELT with GNews fallback, mentions USPTO soft-fail until reactivated, and returns structured data grouped by source. No contradictions with annotations.

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

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

The description is dense but well-structured, starting with example queries, then explaining the fan-out logic, parameter details, and alternative tool. It is efficient but could be slightly more concise by reducing redundancy. Overall, it earns its space.

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

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

Given the tool's complexity (multiple sources, fallback, soft-fail), the description covers essential aspects. It explains the return structure (changes[] grouped by source) briefly. No output schema exists, so this is adequate. Could mention pagination or rate limits, but not critical for typical use.

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

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

Schema coverage is 100% with all parameters described. The description adds significant meaning: it explains 'since' with examples of ISO date and relative shorthand (e.g., '7d', '30d'), recommends '30d' or '1m' for monitoring, and clarifies 'value' can be ticker or CIK. This goes beyond the schema's basic descriptions.

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

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

The description starts with example queries clearly indicating the tool's purpose: returning a change feed for a company in a specified time window. It explicitly states it fans out to SEC EDGAR, GDELT→GNews, and USPTO, and distinguishes itself from sibling tool 'entity_profile' by contrasting 'static profile'.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: 'Use entity_profile instead when you want the static profile...'. It also gives concrete example queries showing typical usage scenarios, and explains the fallback mechanism for news sources.

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

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

Description adds key context: scoped by identifier, persistence (24h for anonymous vs permanent for authenticated). Annotations confirm idempotent and non-destructive. No contradiction.

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

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

Three sentences efficiently cover purpose, use case, and behavior. Front-loaded with primary purpose.

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

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

For a simple key-value store with no output schema, description covers storage behavior, persistence, and pairing with other tools. Complete enough for agent use.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds examples but does not significantly expand beyond schema.

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

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

Description clearly states the tool saves data for reuse across conversations/sessions, provides specific examples, and distinguishes from siblings by mentioning recall and forget.

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

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

Explicitly tells when to use it ('when you discover something worth carrying forward') and includes examples and persistence notes, but does not explicitly mention when not to use.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses cascading internal lookups, graceful degradation if GLEIF/OpenFIGI is unavailable, explicit unresolved identifier reporting, and source labeling for every identifier. This adds meaningful behavioral context not available from annotations alone.

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

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

The description is long but dense with valuable information, front-loaded with user-phrase examples and the 'Use FIRST' directive. Each clause contributes functional detail, though it could be tightened without losing meaning.

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

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

Given the tool's complexity and lack of an output schema, the description covers input formats, output content (identifiers, sources, unresolved fields), supported entity types, examples, and fallback behavior. This is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% and param descriptions already define type/value. The description adds extra semantics: company accepts ISIN input, ISIN resolves via GLEIF to the issuing legal entity, and drug returns RxCUI/ingredient/brand. This goes beyond the schema while not being strictly necessary.

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 ('resolve') and clearly states the resource: converting user-spoken names to canonical identifiers. It distinguishes itself from sibling tools by explicitly saying 'Use FIRST whenever you have a name but need an ID' and enumerating supported entity types.

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

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

The description gives a clear usage directive ('Use FIRST whenever you have a name but need an ID.') and explains that it replaces 2-3 manual lookups. It does not explicitly mention alternatives or when-not-to-use cases, but the context is strong and immediately 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, idempotentHint, openWorldHint as true, and destructiveHint false. The description adds behavioral context: it probes each entity with ai_visibility_check, ranks by score, surfaces most/least recognized, and returns score, confidence, signal density. This goes beyond annotations.

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

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

Three sentences: function, mechanism, use case, output. Front-loaded with action, no fluff. Each 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 no output schema, the description adequately describes return format (ranked list with score, confidence, signal density). It mentions the use case, references a sibling tool, and covers key constraints (apiKey for anthropic). No important gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by noting that the first entity in the array is treated as the 'subject' for narrative, a key semantic not in the schema. This justifies a higher score.

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 compares AI visibility across multiple entities side-by-side, using ai_visibility_check probes and ranking. It distinguishes itself from siblings like ai_visibility_check (single entity) and compare_entities (generic) by focusing on AI presence competitive analysis.

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 context: 'Useful for competitive AI-marketing audits' with an example question. It implies multi-entity comparison but does not explicitly state when not to use it or mention alternatives like using ai_visibility_check for single entities.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: partial failures with graceful degradation, bundlephobia's first measurement delay (5-30s), and that sources_failed will list timeouts. 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 a single dense paragraph, front-loaded with the core purpose. Every sentence adds value: composite nature, when to use, ecosystem scope, failure behavior, and output format. No excess 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?

Despite no output schema, the description details the return structure: summary block with specific fields, per-advisory detail, links, and alternative versions. It also addresses partial failures and timeouts. Comprehensive for a 2-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 description coverage is 100% with clear parameter descriptions. The description adds extra context: scoped packages are accepted, version defaults to latest when omitted. This enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose as a composite check for adding npm packages, specifying the resources consulted (deps.dev and bundlephobia) and the return fields. It distinguishes itself from sibling tools by focusing on npm package evaluation.

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: 'whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also notes ecosystem limitations (NPM only) and directs to alternatives for other ecosystems (deps.dev:version directly).

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

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

Annotations indicate readOnly, openWorld, idempotent, non-destructive. Description adds details about embedding model (BGE-base-en), chunking (500-char overlapping windows), character limit (200K with truncation+flag), and return of offsets. 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, front-loaded with the core action, and every sentence adds value. 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?

Despite no output schema, description explains return values (passages with offsets and similarity scores), limits (200K, 1-20 passages), and behavior (truncation, embedding details). Covers all necessary information for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds significant meaning: for `text` specifies max length and truncation behavior; for `query` gives natural-language examples; for `limit` specifies range and default. Exceeds 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?

Title and description clearly state the tool performs semantic search inside a fetched record. The verb 'search' and resource 'text inside a record' are specific, and the description distinguishes it from siblings by mentioning pairing with ask_pipeworx_grounded.

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

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

Explicitly says to use when the record is too large for the prompt, and mentions pairing with ask_pipeworx_grounded. Provides clear context for when this tool is appropriate.

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 concrete behavioral details beyond annotations: requires non-anonymous/BYO accounts, SMS throttling (10/day), webhook signing secret returned once, auto-disable after 10 failures. Annotations (idempotentHint=true, openWorldHint=true) are consistent and description enriches them.

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

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

The description is well-structured and front-loaded, but some details (e.g., phone verification, webhook auto-disable) could be more succinct. Still, 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 no output schema and nested objects, the description covers prerequisites, supported types, parameter constraints, delivery options, and limitations (SMS cap, webhook secret). Complete for a subscription creation 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?

Despite 100% schema coverage, the description adds value by explaining type-specific parameters (e.g., items for sec_8k, topic for polymarket_edge) and delivery channel semantics (e.g., webhook signing).

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns a subscription ID. It distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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 requirements (Pipeworx OAuth account), lists supported subscription types with examples, describes delivery channels, and mentions alternatives (list_subscriptions to view, unsubscribe to remove).

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

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

Discloses that it returns example questions with tool/argument shapes from a live catalog, and explains behavior when no args vs topic. Annotations already indicate safe/read-only/idempotent, but description adds context about response content.

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

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

The description is front-loaded with common question patterns and includes examples, but is slightly verbose. Every sentence adds value, though some repetition could be trimmed.

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 simplicity of the tool (0 required params, no output schema), the description fully covers what it returns, when to use, and how to use it. No gaps remain.

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

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

Schema coverage is 100% with a basic description; the description adds concrete examples of topic values and clarifies that omitting gives a full spread. This provides meaningful guidance beyond the schema.

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

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

The description clearly states that the tool returns category-bucketed example questions and serves as an onboarding entry point, with specific verb 'returns' and resource 'example questions'. It distinguishes from siblings like ask_pipeworx by emphasizing suggestion/onboarding role.

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

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

Explicitly tells when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you.' Also explains how to use with no arguments vs topic parameter, and mentions alternatives like meta-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?

Beyond annotations (idempotent, non-destructive), the description adds critical behavioral details: ownership enforcement and deactivation (not deletion), ensuring historical data remains available. 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?

Two sentences, front-loaded with the action, and each sentence provides essential information 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 simple tool (one parameter, no output schema), the description fully covers purpose, ownership, side effects, and relation to other tools like 'recent_alerts'.

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

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

With 100% schema coverage, the description's mention of 'by id' adds no new semantics beyond the schema's description of the 'id' parameter. Baseline score is appropriate.

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

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

The description clearly states the action ('Cancel') and the resource ('subscription by id'). It distinguishes itself from siblings like 'list_subscriptions' and 'subscribe' by specifying cancellation.

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 ownership enforcement ('only cancel your own subscriptions'), providing clear context on when it is appropriate. It also notes the deactivation behavior linking to 'recent_alerts', 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?

Beyond the annotations (readOnly, openWorld, idempotent, destructiveHint false), the description discloses important behavioral semantics: the special meaning of could_not_verify and unsupported, the presence of verification_error, and the instruction not to treat could_not_verify as evidence. These details are not available from annotations and are critical for correct interpretation of results.

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 well-structured: it front-loads with trigger phrases and a clear purpose, then logically covers routing, return values, and caveats. Every section earns its place, and there is no redundancy with the schema or annotations. It is not bloated, though a couple of sentences could be trimmed without loss.

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 only 2 parameters and no output schema, the description is fully self-sufficient: it explains the return values (verdict, value with citation, reasoning), the routing logic for financial vs. other claims, and the nuanced handling of could_not_verify and unsupported. This is an excellent example of a complete description for a complex 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?

The input schema already covers both parameters at 100%, providing baseline utility. The description adds valuable extra semantics by giving concrete claim examples and explaining tolerance_pct overrides the implied tolerance, is capped at 5, and should be set to 1–2 for hallucination detection. This adds meaningful usage guidance beyond the schema.

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

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

The description clearly identifies natural-language claim verification against authoritative sources, with a specific verb (validate/verify) and a well-defined resource. It is not tautological and does not repeat the title, but it does not explicitly name sibling alternatives, so it falls short of full distinction.

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

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

The description explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct,' giving clear context for when to invoke it. It also explains internal routing (company financial vs. other claims) but does not provide explicit when-not-to-use guidance or name alternative tools, missing the top score.

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