Vat

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 context: default model is free, probing Anthropic requires BYO key, and return structure includes per-model and combined views. 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 concise (3 sentences) and front-loaded with the core action and result. Every sentence adds value: purpose, default model with cost implication, use cases. 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, the description explains the return structure per-model and combined. It covers all parameters, use cases, and cost implications. For a tool of this complexity, the description is complete and self-contained.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema: explains `entity` as 'The thing to ask about', clarifies `models` supported, notes that `_apiKey` is needed only for Anthropic, and explains `context` as disambiguation aid. This enhances parameter 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 uses specific verbs ('probe', 'score') and identifies the resource ('one or more LLMs', 'business/brand/product/topic'). It clearly distinguishes the tool from siblings by its unique function of AI visibility scoring.

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

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

The description provides clear usage contexts like 'AI-marketing audits, pre-launch brand checks, competitive monitoring' and explains when to pass `_apiKey` and `models`. It does not explicitly state when not to use it or compare to sibling tools, but the context is adequate.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context: it routes through 5,462 tools, fills arguments, returns structured answers with stable pipeworx:// citation URIs, and works on every tier. This goes 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 a single, well-structured paragraph that front-loads the most important directive and flows from scope to mechanism to examples to escalation paths. While longer than minimal, each sentence serves a purpose for a tool of this complexity, with no redundancy.

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

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

For a complex router tool, the description covers all necessary context: supported domains, example queries, routing behavior, citation format, when to use alternatives, and even availability across tiers. This is sufficient given the lack of an output schema; the description explains the answer includes citation URIs.

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

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

The schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description enriches this by providing concrete example questions ('current US unemployment rate', 'Apple's latest 10-K') that illustrate expected input format and scope, adding value beyond the schema's generic 'natural language' 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's function: it routes questions to the right one of 5,462 tools and returns structured answers with citations. It distinguishes itself from siblings by positioning ask_pipeworx as the default entry point, with specific alternatives named for different use cases.

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

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

Explicit guidance is provided: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions,' with example phrasings like 'what is' and 'look up.' It also states when to step up to alternatives (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions), giving clear when-to-use and when-not-to-use conditions.

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

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

The description adds substantial behavioral context beyond annotations: candidate routing improvements are enabled live when under test, no candidate is active now, and it currently matches ask_pipeworx exactly. It also clarifies there is no fallback—it is a fully working router—which is valuable for risk assessment.

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

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

The description is somewhat lengthy but every sentence serves a purpose: explaining beta status, current equivalence, usage, and experimental nature. It is front-loaded with the core purpose and organized logically, though it could be tightened slightly.

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 current behavior, usage, and the mechanism for comparing against the stable router. It omits explicit return-value details but references the same response shape as ask_pipeworx, which is sufficient given no output schema and the tool's simple single-question interface.

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 six parameters are aliases for the same question field, and the schema already documents them thoroughly. The description only references 'same arguments' without adding new parameter-level semantics, so baseline 3 is appropriate.

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

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

The description clearly identifies this as the beta version of ask_pipeworx, a universal router with the same 5,462 tools, arguments, and response shape. It distinguishes itself from the sibling ask_pipeworx by noting candidate routing improvements and its experimental edge.

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

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

Explicitly instructs to use it exactly like ask_pipeworx when wanting the newest routing, and explains results are compared against the stable router. It does not mention when not to use it, but the context is clear enough for a beta variant of a known tool.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses critical behavioral traits: it refuses when the data isn't directly present, returns a specific refusal_reason set, and consumes an extra LLM call. It also explains the exact success/refusal return shapes, which is essential for a grounding tool. No annotation contradiction exists.

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

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

The description is longer than average but every sentence carries essential information: purpose, routing, extraction behavior, return contract, refusal handling, use cases, and cost trade-off. It is front-loaded with the core message and uses structured punctuation for readability, though it could be tightened slightly by separating the return schema into a more scannable form.

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

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

With no output schema, the description fully compensates by detailing both the success return object and all five explicit refusal_reason values. It also includes the extra call cost and relationship to ask_pipeworx, making the tool's operational context complete for an agent to decide and invoke correctly.

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

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

The input schema has 100% description coverage, with every parameter (q, text, input, query, prompt, question) clearly marked as an alias. The tool description adds no detailed parameter semantics beyond what the schema already provides, so the baseline score applies.

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

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

The description opens with a specific, vivid verb phrase: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly states the tool extracts answers using only tool-result content and differentiates itself from its sibling 'ask_pipeworx' by noting same routing but a stricter, evidence-grounded behavior. This makes both the action and the unique value proposition unambiguous.

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

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

The description explicitly states when to use this tool ('Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts') and when to prefer the alternative ('Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.'). It also provides concrete examples of high-stakes domains, making the decision boundary 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 indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds extensive behavioral context: resolver contract (match confidence, alternatives, suggestions), parent_event extractor, news fallback fields, safety short-circuits for low confidence/closed markets, wide-spread warning, and resolution-rule risk. No contradictions with annotations.

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

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

The description is long but well-structured with sections like RESPONSE SHAPES, RESOLVER CONTRACT, etc. Every sentence adds value, but it could be more concise. However, given the complexity, the length is justified.

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

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

The tool is complex (3 params, no output schema, rich behavior). The description covers input formats, classification, fan-out examples, response structure, safety and edge cases (low confidence, closed markets, wide spreads, cancellation rules). It is complete for an agent to use effectively.

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

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

Schema coverage is 100% (all 3 parameters described). The description adds meaning beyond the schema: explains that 'market' accepts slug, URL, or question text; 'depth' defines quick vs thorough; 'include_raw' controls payload size. This adds value on top of 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 researches a Polymarket bet by pulling Pipeworx data, resolving the market, classifying the bet, fanning out to data packs, and returning an evidence packet with comparison. It distinguishes itself from sibling tools like polymarket_edges and polymarket_arbitrage by being a comprehensive research call.

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

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

The description explicitly states when to use the tool: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It provides examples of fan-out for various categories but does not explicitly mention when not to use it or compare to alternatives, though the purpose is clear.

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

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

The description discloses data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return format (paired data + citation URIs). Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds valuable context beyond these hints without contradiction.

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

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

The description is comprehensive but slightly verbose. It front-loads trigger phrases and then provides detailed explanations. While every sentence adds value, some redundancy could be trimmed (e.g., repeating 'parallel call' concept). Overall, it is well-structured and informative.

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

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

Given the tool has only two parameters and no output schema, the description adequately covers what each parameter does, what data is returned (financials for companies, adverse events for drugs, sorted by metric), and includes citation URIs. It provides sufficient context for correct invocation without the need for extensive additional information.

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

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

The input schema already provides clear descriptions for both required parameters (type with enum, values with min/max and examples) with 100% coverage. The description adds significant meaning by detailing what data is pulled for company vs. drug types, how values should be formatted (tickers/CIKs vs drug names), and the result ordering. This enriches the schema beyond the baseline of 3.

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

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

The description clearly states that the tool performs side-by-side comparisons of 2–5 companies or drugs in a single parallel call. It specifies the verb 'compare', the resources (companies/drugs), and provides trigger phrases. It distinguishes from sibling tools like entity_profile by explicitly advocating preference over sequential lookups.

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

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

The description explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and explains the context (comparing entities vs. single lookups). It provides specific scenarios (e.g., 'which is bigger / better') and notes the efficiency gain, replacing 8-15 sequential lookups. No exclusions are needed as the tool is designed specifically for comparisons.

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

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

Annotations already mark readOnly, openWorld, idempotent, non-destructive, but the description adds substantial behavioral context: account/payment requirements, parallel routing, second-hop iteration, gap recovery, contradictions[], citation guarantees, semantic excerpting, latency expectations, and explicit 'never invented' honesty. No contradictions with annotations.

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

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

The description is long but every sentence carries meaningful information—prerequisites, alternatives, output packet details, latency, citation behavior. It could be better structured (e.g., sub-bullets), but given the tool's complexity, the density is justified and front-loaded with the most important caveat (account requirement).

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 covers return values (findings packet, gaps[], contradictions[], hop field, citation_uri), behavioral constraints (latency, paid tier), and usage context (alternatives, prerequisites). It is complete for a tool of this complexity, covering all dimensions an agent needs to invoke it correctly.

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

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

Schema covers 100% of parameters with descriptions, but the description enriches them: it explains the practical difference between depth levels (quick/standard/thorough) beyond the schema's brief enum, and clarifies that 'question' can be broad/multi-part. This adds value over the schema alone.

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

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

The description opens with a specific verb+resource: 'Grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources' and clearly distinguishes itself from open-web search. It explicitly contrasts with sibling ask_pipeworx for single lookups and breaking news, making the tool's niche unmistakable.

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

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

Usage guidance is explicit and detailed: 'Best for broad/multi-part questions over structured data' and 'For a single lookup use ask_pipeworx' plus 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'. It also provides prerequisites (account required) and depth-specific behavioral differences, giving clear when-to-use and when-not-to-use 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, covering safety. Description adds value by stating results are ready to call directly and include schemas, but does not disclose pagination or ordering details.

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 a single, well-structured paragraph that front-loads the core purpose, then provides usage context, output details, and a call to action. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description adequately explains the return value (tools with names, descriptions, and schemas). It doesn't elaborate on ranking or limits, but given simplicity and annotations, it is sufficiently complete.

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

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

The description adds significant context beyond the schema: explains 'query' as a natural language description with examples, mentions aliases, and gives concrete use cases. This helps the agent craft effective queries.

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 finds tools by describing data or task, and distinguishes from sibling tools by being a discovery/ browsing tool. It lists specific domains and explains the output format, ensuring no ambiguity.

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

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

Explicitly instructs 'Call this FIRST when you have many tools available and want to see the option set', providing clear when-to-use guidance. Also gives example queries and mentions alternatives are not needed.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds rich behavioral context: fan-out across sources, patent sunset (soft-fail), GDELT→GNews fallback, and sort order of fundamentals. 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 dense and front-loaded with the key purpose. Every sentence contributes useful information, though the structure could be improved with clearer separation of features (e.g., bullet points). Still, it is efficient and avoids verbosity.

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

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

For a complex tool with 2 parameters and no output schema, the description covers inputs, data sources, return fields, and limitations (patent sunset). It does not detail the exact JSON structure of the output, but given the absence of an output schema, it provides sufficient context for an agent to understand the tool's capabilities.

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 value by explaining that type is currently limited to 'company' and that value accepts ticker or zero-padded CIK (not names). It clarifies the parameter semantics beyond the schema descriptions.

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

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

The description clearly defines the tool's purpose: generating a holistic profile of US public companies by aggregating data from multiple sources in a single call. It explicitly contrasts with chaining individual lookups and distinguishes from sibling tools like resolve_entity.

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

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

Provides explicit guidance: ALWAYS PREFER this tool over chaining when a holistic view is requested, and instructs to use resolve_entity when only a company name is available. This clearly differentiates usage from siblings and sets appropriate expectations.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description 'Delete' aligns with these, but adds little extra behavioral context (e.g., what happens if key doesn't exist, performance implications, or permission needs). With annotations present, the description meets a baseline but doesn't significantly enhance transparency.

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

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

The description is three short sentences, front-loaded with the action and purpose. Every sentence adds value: action, usage context, and related tools. No unnecessary words or redundancy.

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

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

For a simple tool with one parameter, no output schema, and good annotations, the description covers the main use cases and links to siblings. It could mention behavior on missing keys for completeness, but overall it's sufficient for the tool's complexity.

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

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

Schema coverage is 100% for the single parameter 'key', which is well-described as 'Memory key to delete'. The description merely repeats 'by key', adding no additional semantic value beyond the schema. Given high schema coverage, baseline of 3 is appropriate.

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

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

The description explicitly states 'Delete a previously stored memory by key', providing a clear verb-resource combination. It also mentions sibling tools 'remember' and 'recall', distinguishing the tool's purpose for deletion vs. storage or retrieval.

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 specific when-to-use scenarios: 'when context is stale, the task is done, or you want to clear sensitive data'. It also pairs with 'remember' and 'recall', helping the agent understand the workflow. However, it doesn't explicitly mention when not to use it or list alternatives beyond the pairing.

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 as false. The description adds behavioral details: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' This complements the annotations without contradiction.

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

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

The description is two sentences plus a list of use cases. It is front-loaded with the action and output format. No redundant words; every sentence adds value succinctly.

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 low complexity (2 simple params, no output schema), the description fully covers what the tool does, its input requirements, output format ('single text blob'), and intended use cases. 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 both parameters described adequately (url, max_links with default/max). The description reuses the schema descriptions verbatim and adds no new semantic information beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Generate') and resource ('llms.txt file for any URL'), and explains the extracted elements (title/description/key links). It distinguishes from sibling tools like 'scan_competitor_ai_presence' and 'ai_visibility_check' by focusing on generating a standard file format.

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: getting a client's site indexed, drafting for own project, auditing competitor visibility. It does not mention when not to use or alternatives, but the provided contexts are sufficiently clear 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 already declare readOnlyHint, idempotentHint, and destructiveHint as false. Description adds return field details and scope ('caller's active'), but no extra behavioral traits beyond annotations.

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

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

Two concise sentences: first states purpose and return fields, second provides usage guidance. No redundancy or filler.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers purpose, return fields, and usage context. Annotations cover behavioral safety.

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

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

Schema coverage is 100% and the description does not add additional meaning to the single parameter 'include_inactive' beyond what the schema already provides.

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

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

The description clearly states 'List the caller's active subscriptions' with specific verb and resource, and lists return fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

Provides explicit usage advice: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This guides the agent on when to invoke, though no explicit when-not or alternatives are stated.

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

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

The description does not add behavioral context beyond the annotations, which already declare the tool as read-only, non-destructive, and idempotent. No additional traits like return format or rate limits are disclosed.

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, direct sentence with no unnecessary words. It efficiently conveys the tool's purpose.

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

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

Given there are no parameters, no output schema, and the annotations cover safety, the description is adequate. However, it could hint at the output structure (e.g., a list of country codes and patterns) to be more complete.

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

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

The tool has zero parameters, so the description does not need to add parameter semantics. The base score of 4 applies as per the guideline for 0 parameters.

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

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

The description clearly states the tool lists supported countries and their VAT-number formats. The verb 'list' and resource are specific and unambiguous. It distinguishes itself from sibling tools like list_subscriptions by focusing on VAT formats.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it, prerequisites, or context for its application.

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, etc.), so the description carries the burden. It discloses rate limiting ('Rate-limited to 5 per identifier per day'), quota exemption ('Free; doesn't count against your tool-call quota'), and the feedback handling process ('team reads digests daily and signal directly affects roadmap'). It also adds scope constraints like not pasting end-user prompts. No contradictions with annotations.

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

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

The description is long but every sentence adds value: purpose, usage triggers, exclusions, content guidance, rate limit, and quota impact. It is front-loaded with the core purpose, though slightly dense as one paragraph; breaking into structured bullets might improve scannability without changing 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?

For a feedback-submission tool with no output schema, the description covers all necessary contexts: what to report, when, scope boundaries, how to describe issues, rate limits, and cost implications. It fully equips an agent to decide when and how to invoke this tool correctly.

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

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

The input schema already provides 100% coverage with detailed descriptions for all three parameters, including enum explanations for type. The description adds contextual guidance (e.g., 'Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), but this is supplementary and not essential because the schema already explains each parameter.

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

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

The description states the tool's precise purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly maps to feedback categories (bug, feature, data_gap, praise) and distinguishes itself from sibling tools like ask_pipeworx and discover_tools by focusing on submitting feedback to the Pipeworx team.

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

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

The description provides explicit when-to-use guidance with concrete examples: use for wrong/stale data (bug), missing catalog tools (feature/data_gap), or praise. It also gives a clear when-not-to-use exclusion: only for tools served by this Pipeworx connection, not other MCP servers, and suggests filing with that server instead.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds significant behavioral context: data source (CF analytics-engine), no PII, caching behavior (5min-1h). This goes beyond annotations and fully informs the agent.

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 extremely concise with two sentences plus a bullet list. It is front-loaded with the main output, and every sentence adds value without redundancy.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers purpose, usage, data source, privacy, and caching. No significant 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?

Only one parameter (window) with 100% schema coverage. The description adds meaning beyond the enum by explaining that shorter windows surface hot trends while longer windows show steady-state demand, aiding selection.

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 call volume over a window. It provides three specific use cases, distinguishing it from sibling tools like discover_tools or generate_llms_txt, 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 scenarios where the tool is useful (discovering hot data, confirming canonical choice, seeing alignment). While it doesn't mention when not to use it or alternatives, the guidance is clear and context-rich.

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

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

Annotations declare readOnlyHint, idempotentHint, and non-destructive. Description adds internal logic details (semantic anchor, partition filter, fill check) that go 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?

The description is long but well-structured with clear sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). It is informative but could be slightly more concise without losing clarity.

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

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

Despite no output schema, the description explains the response structure (opportunities array, partition_check, fill check) and covers edge cases (placeholders, similarity filtering). It also references sibling tools for additional context.

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

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

Schema coverage is 100% with descriptions. The description adds contextual meaning (e.g., event slugs, topic seeding, and behavior differences) that enhances understanding beyond the schema alone.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks, and distinguishes between three modes (no args, event, topic). It uses specific verbs and resources.

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 each mode: 'Call with NO args for a `trending_scan`', 'pass `event` for a specific market', '`topic` for cross-event scan'. Also provides guidance on when not to trade (realizable_edge_pp ≤ 0) and suggests polymarket_fill_risk for custom sizing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. The description adds significant behavioral context: caching at 1h KV level keyed on knobs, tradeable-edge knobs, slippage assumptions, diagnostics for empty segments, and Fed bets exclusion. 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 very dense, containing detailed model family explanations that may be excessive for tool invocation. While it is structured with clear sections (model families, segments, knobs, response top-level), it could be more concise. The front-loaded purpose is good, but the length may overwhelm agents.

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 9 parameters, no output schema, and high complexity, the description covers output structure (by_segment, diagnostics), edge cases (Fed bets, empty segments), caching, and filter behavior. It explains why segments might be empty and provides diagnostics, making the tool's behavior fully transparent.

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

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

Schema coverage is 100% with good descriptions. The description adds value beyond schema by explaining how parameters interplay (e.g., 'Bump for very thin partitions; drop to 0 if you have a smarter fill model') and grouping them under 'TRADEABLE-EDGE KNOBS'. This compensates for the baseline 3.

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

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

The description clearly states the tool scans top Polymarket markets for opportunities where Pipeworx data disagrees with market price, specifically built for 'what should I bet on today'. The verb 'scan' and resource 'top Polymarket markets' are explicit, and the purpose of discovering edge opportunities is distinct from siblings like polymarket_arbitrage and polymarket_edge_tracker.

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

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

The description clearly states the tool is for agents to discover opportunities without paging through hundreds of markets, providing a clear use case. However, it does not explicitly say when not to use it or point to alternatives among siblings, leaving some guidance implicit. The detail on internal model families may help agents understand output but adds cognitive load.

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive behavior. The description extends this by detailing response structure (tracked, expired, snapshot_dates), computation of trend and decay, signed values, and limitations (TTL, snapshot gaps). 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 front-loaded with the core purpose and question, followed by detailed response fields and limitations. While dense and informative, it could be slightly more concise by trimming some redundant phrasing.

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 absence of an output schema, the description thoroughly explains the return structure (tracked items with time-series, expired items with lifespan, snapshot dates) and includes important context like decay computation and snapshot TTL. Covers all necessary aspects for effective usage.

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

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

Schema coverage is 100% but description adds value by specifying default values (14 for days, '1wk' for window), clamping range (2-30), and clarifying the meaning of 'window' as snapshot family. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose as providing edge persistence and decay telemetry from daily snapshots. It answers a specific user question ('how long has this edge existed and is it shrinking?') and distinguishes itself from the sibling tool 'polymarket_edges' by focusing on temporal depth rather than single-snapshot data.

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

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

The description explains when to use the tool (to understand edge persistence over time) and provides context with a concrete example differentiating fresh vs. old edges. However, it lacks an explicit statement of when NOT to use it or direct comparisons to alternatives among sibling tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant context: it explains the tool walks the ladder, returns top_of_book, VWAP fill price, slippage, shares filled, verdict, etc. It also warns about forced directional risk and partial fills. No contradiction with annotations.

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

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

The description is well-structured with clear sections for single-market and basket modes, and it front-loads the purpose and requirements. However, it is quite verbose and could be tightened without loss of clarity. Every sentence adds value but some technical detail could be condensed.

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 (two modes, multiple return fields), and the absence of an output schema, the description is remarkably complete. It covers all key return fields (top_of_book, VWAP, slippage, verdict, etc.), explains forced directional risk, and provides detailed usage conditions. No gaps evident.

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

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

Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains that exactly one of `market` or `event` must be provided, defaults for `size_usd` and `side`, and the interpretation of `size_usd` differs between modes (spend vs target proceeds vs settlement notional). It clarifies the auto side selection for basket mode based on partition sum.

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 a realizable-vs-theoretical edge check against live order-book depth, with two distinct modes (single-market and basket). It uses specific verbs ('checks', 'walks the ladder') and resources ('live CLOB order-book depth'). It distinguishes itself from sibling tools by specifying it is a pre-check before executing arbitrage or edge trades.

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: before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500. Provides reasoning: theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position. This effectively tells when not to use alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes far beyond by detailing safety fields (compatibility_warning, temporal_alignment, skipped counters), explaining when spreads are meaningless (temporal mismatch, non-equivalent bet shapes), and warning that most pre-mapped topics return warnings. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and then details modes, response, and safety fields. It is slightly long but each sentence adds value; no redundancy. Could be tightened slightly but retains necessary technical details for accurate usage.

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 thoroughly explains the response structure (raw probabilities, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters) and all edge cases. The tool's complexity (3 parameters, cross-venue logic) is fully covered.

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

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

Schema coverage is 100% and the description adds substantial meaning: it lists the exact topic shortcuts, provides examples, explains override behavior for explicit parameters, and gives concrete examples like 'KXFED-26OCT' and 'fed-decision-in-june-825'. This fully compensates any schema limitations.

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 cross-venue spread between Kalshi and Polymarket for the same resolving question, distinguishes from siblings like polymarket_arbitrage by focusing on cross-venue comparison, and specifies both modes of operation. The verb 'cross-venue spread' is specific and resource-oriented.

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

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

The description explains when to use the tool (to compare prices across venues) and provides explicit context for interpreting safety fields and warnings about pre-mapped topics. It does not directly compare to alternatives but the sibling list makes the distinction clear. It includes practical guidance on mode selection and handling of compatibility warnings.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable scoping detail ('scoped to your identifier') and clarifies the listing behavior when key is omitted.

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 efficient: two sentences with the core behavior front-loaded, followed by two short sentences on scoping and pairing. 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 the tool's simplicity (1 param, no output schema, clear annotations), the description is fully complete, explaining behavior, scoping, and relationships to sibling tools.

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 restates what the schema already says about the 'key' parameter (omit to list). It adds no additional semantic 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's core action: retrieve a value by key or list all keys when omitted, explicitly distinguishing it from siblings like 'remember' and 'forget'.

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

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

The description explains when to use the tool—'look up context the agent stored earlier'—and mentions pairing with 'remember' and 'forget'. It lacks explicit 'when not to use' but provides sufficient 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?

The description clearly discloses the mark_read side effect and what return fields to expect, adding value beyond annotations. However, the mark_read write behavior slightly contradicts the readOnlyHint annotation, though the description transparently addresses it.

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, efficiently covering purpose, return fields, filtering, side effects, and alternative access. It is front-loaded and concise, though a bit 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?

Given the absence of an output schema, the description covers return fields and parameter usage well. Annotations provide safety cues. The tool is relatively simple, and the description adequately prepares the agent for invocation.

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

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

With 100% schema coverage, the description adds meaningful context: explaining the purpose of each parameter (e.g., 'ISO timestamp', 'Flag the returned events read') and providing an example for type ('sec_8k'). This enhances understanding beyond the schema alone.

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

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

The description clearly states 'Pull fired events from your subscription feed' with a specific verb and resource. It details the return fields (source, citation_uri, raw payload) and distinguishes itself from sibling tools like list_subscriptions by focusing on actual alerts rather than subscriptions.

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

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

The description provides explicit context: 'Poll works fine' and mentions an alternative access method (GET endpoint). It also explains filtering by type and since. However, it does not explicitly state when not to use this tool versus alternatives like recent_changes.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds details about data sources (SEC, GDELT→GNews fallback, USPTO), fallback behavior, and potential API issues (USPTO soft-fail). This provides rich behavioral context beyond the annotations.

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

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

The description is a single paragraph that is well-structured with front-loaded examples. Although it is somewhat long, every sentence adds necessary 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 tool's complexity (multiple sources, fallback, time formats, output structure) and the absence of an output schema, the description provides comprehensive information: what the tool returns, sources used, fallback logic, and a comparison with entity_profile. It is fully self-contained for agent usage.

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

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

Schema covers all parameters with descriptions. The description adds value by explaining the 'since' parameter format with examples and a recommendation ('30d' or '1m'), and clarifying that 'value' accepts either 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 clearly states it provides a change feed for a company, with examples like 'What's new with X' and 'latest on Y'. It distinguishes from sibling tool 'entity_profile' by specifying when to use that instead.

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 explicit guidance on when to use entity_profile instead, and implies when to use this tool through examples. However, it does not explicitly list all scenarios where this tool should not be used, but the alternative is clearly stated.

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

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

Adds significant behavioral context beyond annotations: scoping by identifier, persistence differences (authenticated vs anonymous), 24-hour expiration for anonymous, and pairing with recall/forget. 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?

Four well-structured sentences with front-loaded purpose. No filler; each sentence adds essential information.

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

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

Complete for a simple write operation: covers purpose, usage, behavioral details, scope, persistence, and suggests companion tools. No missing information given the context signals.

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. Description adds value by providing examples of valid key patterns (subject_property, target_ticker, etc.), which aids in correct usage.

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

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

Description clearly states 'Save data the agent will need to reuse later' and distinguishes from siblings 'recall' and 'forget' by mentioning pairing. It specifies the resource (key-value pairs) and action (save).

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: 'when you discover something worth carrying forward' with examples. Does not explicitly state when not to use, but context implies it's for data needing storage, and alternatives are named.

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. The description adds substantial behavioral context: return fields per type (ticker+CIK+company_name, RxCUI+ingredient+brand), data sources (SEC EDGAR, RxNorm), citation URI schemes, auto-disambiguation behavior, and the internal cascade through multiple endpoints. This greatly enriches what annotations alone provide.

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

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

The description is front-loaded with user-phrased examples, then a crisp definition, then a structured SUPPORTED TYPES list. It is relatively compact for the amount of information conveyed, though the internal cascade note could be considered slightly extra. Overall well-organized and free of padding.

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

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

There is no output schema, so the description must explain return values; it does for both entity types, including sources and citation URIs. It also explains accepted input forms and the tool's efficiency. It omits edge-case/error behavior, but for a read-only lookup tool with strong annotations and schema coverage, the description is sufficiently complete.

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

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

Schema coverage is 100% — both 'type' and 'value' have detailed descriptions with examples. The description mostly repeats these, but it adds the nuance that company input is 'auto-disambiguated' and that each call replaces 2-3 manual lookups, which goes beyond the schema. With baseline 3 for full schema coverage, the extra detail justifies a 4.

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

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

The description opens with concrete user queries ('What's the ticker for…', 'find the CIK for…') and clearly states it resolves a user-spoken NAME to the canonical/official identifier other tools require as input. It distinguishes from siblings by emphasizing it provides IDs needed by other tools and says 'Use FIRST whenever you have a name but need an ID.'

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

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

The description gives explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It does not name specific alternatives or explicitly state when not to use it, but the 'if you need an ID' framing clearly implies that if an ID is already in hand, this tool is unnecessary.

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

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

Annotations already indicate read-only, open-world, idempotent. Description adds that it returns a ranked list with score, confidence, signal density, and that it uses ai_visibility_check internally. No contradictions.

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

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

Two concise sentences with front-loaded main purpose and supporting detail. Every sentence adds value without redundancy.

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

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

No output schema, but description explains return format. Covers input constraints (2-8 entities). References sibling tool. Complete for competitive comparison 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 meaningful context: entity array size (2-8), first as subject, model options, API key purpose, and context disambiguation. This 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?

The description clearly states it compares AI visibility across entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It uses specific verbs and distinguishes from single-entity check sibling.

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

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

Provides clear context for competitive AI-marketing audits with an example question. Implicitly signals when to use (multiple entities) vs single-entity check, but does not explicitly list alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: partial failures degrade gracefully with 'sources_failed', timing delay for bundlephobia first measurement, and the composite fan-out behavior. No contradictions.

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

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

The description is fairly long but dense with necessary information. It front-loads the core purpose and is well-structured, though slightly verbose. 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?

Despite no output schema, the description fully explains the return structure (summary block, advisories, links, alternative versions) and handles edge cases (scoped packages, default version, partial failures). Completeness is high for the complexity level.

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 scoped packages are accepted and that version defaults to latest, beyond the schema descriptions. It also describes the output structure, aiding parameter 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 composite nature of the tool, combining deps.dev and bundlephobia data for npm packages. It distinguishes from sibling tools by specifying the NPM-only scope and directing users to deps.dev:version for other ecosystems.

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

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

The description provides explicit use cases ('is X safe / popular / small' or 'what does adding lodash cost me') and notes limitations (NPM only in v1, partial failures, 5-30s delay for bundlephobia). It lacks explicit when-not-to-use, but it's implicit.

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: BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation and flagging. 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 concise, front-loaded with key information, and every sentence adds value. No unnecessary words or repetition.

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

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

Given no output schema, the description explains return type (passages with character offsets and similarity scores). It also mentions pairing with another tool and technical details (embeddings, cap). Complete for the tool's complexity.

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

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

Schema coverage is 100% so parameters are documented. The description adds extra semantic context: max 200K chars for 'text', default and range for 'limit', and example queries for 'query'. This goes beyond the schema.

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

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

The description clearly states it performs semantic search inside a fetched record, using specific verbs like 'search' and 'get back'. It distinguishes from sibling tools (e.g., ask_pipeworx_grounded) by noting that it works inside a record rather than over a whole document.

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

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

The description explicitly says 'Use when the record is too big to cram into the prompt' and suggests pairing with ask_pipeworx_grounded. It does not explicitly list when not to use, but the clear use case and context are sufficient for 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=false, destructiveHint=false, and idempotentHint=true. The description adds meaningful behavioral details such as return value, delivery channel constraints (10/day SMS cap), webhook auto-disable after 10 failures, and the requirement for phone verification. It does not contradict any annotation.

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

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

The description is information-dense but well-structured, with the core purpose and return value first, followed by type and delivery details. It could be slightly more concise, but every sentence adds value. Slight improvement possible in brevity.

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

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

Given the tool's complexity (3 params, nested objects, no output schema), the description covers purpose, prerequisites, type parameters, delivery options, and return value. It lacks details on error handling, idempotency behavior, or how to update subscriptions, but these are minor gaps. Overall context is strong.

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, baseline is 3, but the description significantly enriches parameter understanding through detailed examples for each subscription type and delivery channel requirements (e.g., phone verification, rate limits). This goes well beyond the schema's basic descriptions.

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

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

The description clearly states the verb ('Create a proactive monitoring subscription'), the resource ('live-data event stream'), and indicates the return value ('Returns the new subscription id'). It differentiates from siblings implicitly as a creation tool, distinct from listing (list_subscriptions) or removing (unsubscribe) subscriptions.

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

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

The description specifies prerequisites ('Requires Pipeworx OAuth account; anonymous + BYO cannot persist subscriptions'), which helps agents decide when to use this tool. However, it does not explicitly distinguish from sibling tools like recent_alerts or list_subscriptions, nor does it state when not to use it.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds valuable context: returns category-bucketed examples, can be called with no args or a topic, and is for orientation. 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 reasonably concise for the amount of information it conveys. It front-loads the purpose with alternative phrasings and then explains the output and usage. Slight redundancy 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?

Given that the output schema is absent, the description adequately describes the return value: category-bucketed example questions with tool + argument shape. Combined with good annotations and a simple single-parameter schema, the description is complete for an onboarding tool.

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

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

Schema coverage is 100% with a brief description for the topic parameter. The description adds meaning by listing specific topic values (finance, pharma, etc.) and explaining that omitting topic gives a cross-category spread, going 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: return category-bucketed example questions for onboarding. It includes multiple query phrasings ('What can I ask Pipeworx?', 'what can you do?') and distinguishes from siblings by explicitly calling it the onboarding entry point.

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

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

Explicitly states when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It does not provide when-not-to-use scenarios, but the context is clear enough.

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

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

Adds important behavior beyond annotations: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts.' This clarifies non-destructiveness, aligning with destructiveHint=false, and explains side effects. 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 concise sentences, front-loaded with the core action. Every sentence adds unique value without redundancy.

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

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

Given one parameter, no output schema, and comprehensive annotations, the description fully covers purpose, usage constraints, and behavioral nuance. No missing information.

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

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

Only one parameter 'id' with schema coverage 100%. Description adds slight value by noting the id is 'returned by subscribe', but overall the schema already describes it. Baseline 3.

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

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

Description explicitly states 'Cancel a subscription by id', clearly identifying the action and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by focusing on 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?

States ownership enforcement ('you can only cancel your own subscriptions'), providing a key usage condition. Does not explicitly mention when not to use or list alternatives, which prevents a 5.

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

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

Annotations indicate readOnlyHint, openWorldHint, and idempotentHint, all of which align with the description. The description goes further by explaining the return value (verdict, actual value with citation, reasoning), the two processing pipelines, and that it replaces multiple sequential calls. No contradictions are present.

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

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

The description is moderately long but well-structured. It front-loads the core purpose with examples, then explains the dual-path behavior and return value. Every sentence contributes useful information without redundancy. Minor reduction could be possible, but it remains efficient.

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

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

For a tool with 2 parameters, no output schema, and rich annotations, the description covers all necessary aspects: what it does, when to use it, how it processes different types of claims, what it returns (verdict, value, reasoning), and behavioral traits. The agent has enough information 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?

Both parameters are fully described in the input schema (100% coverage). The description adds value by explaining that 'tolerance_pct' overrides the implied tolerance from the claim wording, with a default capped at 5%. This provides practical guidance beyond the schema's basic 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 starts with explicit examples of when to use the tool ('Is it true that...', 'fact check', 'verify the claim that...') and clearly states that it performs natural-language claim verification against authoritative sources. It distinguishes from siblings by specifying the specialized pipeline (SEC EDGAR for financial claims, grounded pipeline for others), making the purpose unambiguous and differentiating it from other knowledge retrieval tools.

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

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

The description explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct.' It further details the two distinct paths for company-financial vs. other claims, providing clear context on when to prefer this tool. While it doesn't explicitly list exclusions, the explanation of fallback behavior helps the agent 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?

Adds key behavioral details beyond annotations: 'keyless & offline', format-only validation, and that it does not confirm active registration. 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?

Two sentences, front-loaded with purpose, then usage details and limitations. No irrelevant information.

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

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

For a simple validation tool with no output schema, the description covers purpose, parameters, behavior, and limitations adequately. Return value (boolean match) is implied.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining the two input patterns (prefix vs. national number + country) with examples, providing clarity beyond schema descriptions.

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

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

The description clearly states the tool validates the FORMAT of a VAT registration number for EU+UK/CH/NO. It distinguishes from siblings by noting it does not confirm registration, directing to VIES service.

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 two acceptable input formats (with prefix or separate country code) and clearly notes what the tool does NOT do (not a registration check), guiding when to use alternatives.

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