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 establish readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful operational context: it fills arguments automatically, routes across many sub-tools, and returns structured answers with stable citation URIs. It does not contradict annotations, though the appended meta-text could reduce trust. The non-behavioral tail prevents a 5, but this is solid disclosure.

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

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

The first several sentences are tight, front-loaded, and purposeful, building from preference to behavior to triggers to examples. However, the description then degenerates into recursive, self-referential text ('but wait, the actual description ends differently...') that is not concise, adds no value, and would actively confuse an agent trying to parse the definition.

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 read-only query tool with one required parameter and no output schema, the description covers the core invocation contract: use natural language, the tool routes and returns cited structured answers. But it omits sibling differentiations, failure or fallback behavior, and the exact response shape. The confusing tail also detracts from overall completeness.

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

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

Schema coverage is 100%, and the schema already documents the required 'question' parameter plus aliases. The description reinforces natural-language usage with six varied examples but adds no additional parameter semantics beyond what the schema provides, so the baseline 3 applies.

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

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

The description clearly states a specific capability: routing a natural-language question to one of 5,798 tools across 1,517 verified sources and returning structured answers with pipeworx:// citation URIs. It distinguishes itself from web search, but not from sibling variants like ask_pipeworx_beta or ask_pipeworx_grounded, and the recursive tail ('but wait, the actual description ends differently') slightly muddles the clarity.

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 when-to-use guidance: 'PREFER OVER WEB SEARCH' and 'Use whenever the user asks...' with trigger phrases ('what is', 'look up', 'find', 'get the latest') and concrete examples. It also gives a strong default directive ('START HERE for most questions'). However, it does not mention when-not-to-use conditions or route to sibling alternatives such as deep_research or validate_claim, so it is not fully comprehensive.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive hints. The description adds valuable context: it is an experimental edge with candidate routing improvements, results are compared against stable router, and it falls back to nothing and is fully functional. No contradiction with annotations.

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

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

The description is dense but organized, front-loading the beta relationship and then clarifying current parity, usage, and fallback behavior. It earns its length by covering important experimental context an agent needs before invocation.

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

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

Given no output schema and 6 parameters (mostly aliases), the description fully explains what the tool is, how to use it, when to choose it, and its relationship to the stable sibling. Nothing critical is missing.

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

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

Schema coverage is 100% and the schema documents the 'question' parameter and all aliases. The description adds the meta-context that the router accepts the same arguments as ask_pipeworx, which helps an agent know the question is the single required input despite listing multiple alias 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?

Description clearly identifies this as the beta/experimental version of ask_pipeworx, a universal router with the same tools/arguments/response shape, and explains the live candidate routing test context. It explicitly distinguishes it from the stable router and clarifies it is still a full working router, not a stub.

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

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

The description states to use it exactly like ask_pipeworx when wanting the newest routing, and explicitly says it currently matches ask_pipeworx exactly because no candidate is active. This gives an agent clear conditions for selecting this tool over the stable sibling.

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

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

Discloses the full success and refusal response shapes, including refusal_reason enum values, evidence as verbatim quote, and the extra LLM call cost. This goes well beyond the annotations and gives the agent clear expectations about what happens when data is insufficient or errors occur.

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

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

Every sentence earns its place: mode definition, routing mechanism, success/refusal contract, usage criteria, and cost tradeoff. The return-shape detail is verbose but necessary because there is no output schema. It is dense but not bloated.

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

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

The description is complete for a read-only, grounded QA tool with one question parameter. It covers what the tool does, how it behaves, what it returns, when to use it, and when to prefer the sibling. The input schema covers all parameter semantics, so nothing essential is missing.

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

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

Schema description coverage is 100%, so the input schema already documents the question parameter and its aliases clearly. The description adds context about the grounded answering behavior but does not need to add parameter-level detail. A 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 defines this as a hallucination-resistant, grounded answer mode that picks the right tool, fetches data, and extracts an answer using only the tool result. It distinguishes itself from ask_pipeworx by emphasizing grounded extraction and refusal behavior when data doesn't directly answer.

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

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

Explicitly states when to use: whenever an answer will be quoted, cited, or acted on, and facts must not be invented. Also gives a clear alternative: prefer ask_pipeworx for casual lookups. This is strong, actionable routing guidance.

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

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

Annotations 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 this read-only/idempotent/open-world, and the description layers on substantial context: account/paywall requirements, the findings packet structure (verbatim evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[]), the no-hallucination guarantee, citation resolvability, semantic excerpting behavior, and latency expectations. No contradiction with annotations.

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

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

Long but every sentence carries information; the critical constraint (ACCOUNT REQUIRED + alternative if not signed in) is front-loaded. It loses a point for being a dense wall of text with abrupt transitions (e.g., '(One hop, quick default.)' dropped mid-flow) and for partially re-explaining depth semantics already present in the schema.

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

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

Despite having no output schema, the description fully compensates by enumerating the findings packet fields, gaps[], contradictions[], citation behavior, and latency. Auth, alternatives, and depth-tier semantics are all covered. Nothing needed for correct selection or invocation is missing.

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

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

Schema coverage is 100% and the schema's depth description is already rich, so the baseline is 3. The description adds real selection value beyond the schema: 'thorough' requires a paid plan, latency varies by depth (15-60s, up to ~90s for thorough), and contradictions[] appear only at standard/thorough. This informs parameter choice in ways the schema does not.

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

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

States a specific verb and resource: grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources in ONE call. Explicitly distinguishes itself from open-web search and from sibling ask_pipeworx (single lookup), making it easy for an agent to identify what this tool uniquely does.

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

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

Gives explicit when-to-use guidance (broad/multi-part questions over structured data, with two concrete example questions) and when-not-to-use guidance (single lookups → use ask_pipeworx; not signed in → use ask_pipeworx since it works on every tier). Names the alternative tool directly.

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

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

Annotations 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?

Beyond the readOnlyHint/openWorldHint/idempotent annotations, the description discloses fan-out behavior, soft-failure for the USPTO patents source, the meaning of sources_used/sources_failed, that empty sections indicate real 'no data', and the resolved:false behavior for private companies. This is rich behavioral context not present in annotations.

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

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

The description is long but well-structured: it front-loads the core purpose, then systematically covers behavior, sources, return fields, inputs, and edge cases. Every sentence adds information, but some redundancy with the schema makes it slightly longer than necessary.

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 must explain return values, and it does: cik, company_name, recent_filings, fundamentals, patents, contracts, fda_products, hiring, news, LEI, plus sources_used/failed. It also covers failure modes and private-company behavior, making the tool fully comprehensible.

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 concrete examples (AAPL, 0000320193, Moderna), clarifies that type='company' and type='ticker' behave identically, and mentions name resolution via SEC EDGAR. This goes beyond the schema descriptions, though some repetition exists.

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

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

States a specific verb+resource: full cross-source profile of a US public company in one parallel call. It distinguishes from chaining single-pack SEC/XBRL/news lookups and names its scope (US public company), making it clear what the tool does.

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

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

Explicitly says ALWAYS PREFER over chaining single-pack lookups when the user asks for a holistic view. Also explains input forms (ticker, CIK, name) and the special case for private companies, giving the agent clear when-to-use and edge-case 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 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 only mark all hints false (readOnly, openWorld, idempotent, destructive), so the description carries the burden of explaining side effects. It discloses the claim_token flow ('Filing without an account returns a claim_token; pass it back later...'), rate limiting ('Rate-limited to 5 per identifier per day'), and cost ('Free; doesn't count against your tool-call quota'). These add meaningful behavioral context beyond the sparse 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 in the first sentence, then organized into successive clauses covering when, scope, exclusions, and workflow. Although longer than typical, every sentence earns its place—the 'Not sure?' clarification, claim_token mechanics, rate limit, and quota note all add necessary context. No filler or repetition exists, making it efficient despite its length.

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

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

For a feedback submission tool with no output schema, the description covers all critical angles: purpose, use cases, scope limitations, how to handle tokens, rate limits, and expected turnaround ('team reads digests daily'). It even handles ambiguous cases like 'Not sure?' with a simple heuristic. Given the tool's modest complexity and absent output schema, the description is fully complete for an agent to invoke correctly.

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

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

Schema coverage is 100% with all four parameters described. The description adds genuine value beyond the schema: it explains how claim_token is initially obtained ('Filing without an account returns a claim_token') and provides content guidance for message/context ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'). This goes beyond the baseline and enriches 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 opens with a clear, specific statement of purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It distinguishes itself from sibling research tools by enumerating exact use cases (bug, feature, data_gap, praise) and ties them to specific triggers like wrong/stale data or missing catalog items. This exceeds simple verb+resource clarity and directly separates it from alternatives like ask_pipeworx.

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

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

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

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

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

Annotations already indicate 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?

The description goes far beyond the read-only/idempotent annotations by detailing safety fields, compatibility codes, temporal mismatch semantics, skipped comparisons, and the fact that spreads are gross of Kalshi fees. It discloses that legs with unknown metric types are never paired and that keyword-based pairing is unverified. This is rich, actionable behavioral disclosure with no contradiction to 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 front-loaded with the core purpose and modes, and it is organized via labeled sections. It is, however, very long and dense, covering many edge cases and code lists in one continuous block. Nearly every sentence carries information, but the sheer volume makes it less concise than ideal for quick agent consumption.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly: leg prices, top_spreads_pp, compatibility fields, temporal_alignment, skipped counters, fees_note, and low_confidence_pairs are all described. It also warns about signal validity and non-equivalent bet shapes, giving an agent enough context to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by explaining that both the topic and explicit modes run the identical token-overlap matcher, by listing the ten valid topic shortcuts, and by clarifying override behavior. This is more than the schema alone provides, though not extensive extra parameter detail.

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

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

The description names the exact resource: the cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes the tool from siblings like polymarket_arbitrage by making the Kalshi–Polymarket pairing and same-event matching explicit. The two modes are also clearly stated, so an agent knows what the tool actually fetches and compares.

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

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

The description gives clear usage context: use the topic shortcuts for pre-mapped macros or provide an explicit kalshi_event_ticker plus polymarket_event_slug for custom pairings. It also warns that pre-mapped topics may return compatibility warnings and are not automatically tradeable. However, it does not explicitly contrast this tool with sibling alternatives or say when not to use it.

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

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

Beyond 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?

Beyond the read-only/idempotent annotations, the description discloses multi-source resolution (SEC EDGAR, GLEIF, OpenFIGI, RxNorm), ambiguous-input behavior via figi_candidates, explicit unresolved identifiers, graceful degradation when enrichment sources are down, and ISIN-to-LEI behavior. This gives the agent an unusually clear model of side effects and outputs.

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 content is valuable but delivered as one extremely dense run-on paragraph with nested parentheticals; it could be restructured with bullets or shorter sentences. It is front-loaded with examples and avoids pure padding, but it is not appropriately sized for a two-parameter tool.

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

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

With no output schema, the description supplies enough output expectations (10-digit CIK, ticker, company_name, RxCUI, ingredient, brand, figi_candidates, unresolved) to let the agent interpret results. It covers supported types, input variants, edge cases, and failure modes, so the tool is callable correctly without needing 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?

Even though schema coverage is 100%, the description adds critical interpretation rules: accepted input formats for company (ticker, CIK, ISIN, name), drug name examples, the requirement to pass only the entity name, and the warning that trailing security-class words break bond matching. This materially improves the agent's ability to supply the right value.

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

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

The description opens with concrete user phrasings and states a clear action: resolve a user-spoken NAME to canonical/official identifiers other tools require. It differentiates itself by defining the supported entity types, the sources for each, and by positioning itself as the ID resolver while sibling tools like entity_profile consume IDs.

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

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

It gives an explicit routing rule: "Use FIRST whenever you have a name but need an ID," and illustrates with query examples. It also covers disambiguation and degradation behavior, but it does not name sibling alternatives or explicitly say when not to use it, so it falls just short of full when/when-not guidance.

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

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

Annotations already indicate 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 declare readOnly and idempotent, but the description adds significant behavioral detail: the dual-path routing (structured vs. grounded), the response structure (verdict, value, citation, reasoning), and the critical semantic distinction between could_not_verify (check did not happen) and unsupported (source not covered).

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

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

The description is lengthy but information-dense, packing trigger phrases, routing logic, output details, and caller warnings into one paragraph. Every sentence adds value, though it could be slightly better structured with section breaks for easier scanning.

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

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

Despite no output schema, the description fully covers return values (verdict types, actual value, citation, reasoning) and edge-case semantics (could_not_verify with verification_error). It also explains how the tool integrates into workflows (replacing 4-6 sequential calls), making it complete for a complex tool.

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

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds meaningful context beyond the schema by explaining that tolerance_pct overrides claim-wording implied tolerance and recommending 1-2 for hallucination detection, enriching the parameter's semantics.

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: verifying natural-language claims against authoritative sources, with trigger phrase examples. It distinguishes itself from siblings by describing its specialized behavior (structured SEC path vs. grounded pipeline) and noting it replaces multiple sequential calls.

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

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

Explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct', and differentiates between company-financial and other claims. It also clarifies the meaning of outcome verdicts (could_not_verify vs unsupported), providing clear guidance on interpretation.

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.