Owasp

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details: it probes models non-destructively, uses API keys passed through, and returns per-model plus combined results. 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?

Three sentences: first states purpose and default, second covers optional Anthropic integration, third summarizes output shape and use cases. No filler, front-loaded with the most important information.

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

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

Given 4 parameters (all described) and no output schema, the description sufficiently covers the return structure (per-model and combined view). It lacks explicit details on error handling or rate limits, but for a read-only probe that is acceptable.

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

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

All four parameters are described in the input schema (100% coverage). The description adds meaning by explaining the default model, that `_apiKey` is only needed for Anthropic, and that `context` helps disambiguate. This adds value 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 uses a clear verb ('Probe') and resource ('LLMs for what they know about a business / brand / product / topic'), specifies the output ('score visibility 0-100'), and lists concrete use cases (AI-marketing audits, pre-launch checks). It distinguishes from sibling tools by focusing on AI visibility measurement rather than general search or entity resolution.

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

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

The description states when to use (e.g., AI-marketing audits) and explains the default model vs. requiring an Anthropic key for probing Anthropic. It does not explicitly say when not to use or compare to alternatives, but the purpose is clear enough 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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond this: it routes to 5,462 tools across 1419 verified sources, fills arguments, returns structured answers with stable pipeworx:// citation URIs, and works on every tier in one fast call. It does not contradict 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 compact, front-loaded with the most important directive ('PREFER OVER WEB SEARCH'). Every section earns its place: purpose, routing behavior, when-to-use, examples, and alternatives. It is structured logically, though slightly verbose for a tool that could be summarized more briefly.

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 this tool's complexity. It explains return format (structured answer with citations), provides examples, covers when to use vs alternatives, and notes tier compatibility. Since there is no output schema, this description fully covers what the agent needs to know.

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 fully documents the parameters, including the main 'question' parameter and all five aliases. The description provides examples but does not add significant meaning beyond the schema. Since schema_description_coverage is 100%, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: it routes questions to authoritative structured data sources and returns answers with citations. It uses a specific verb ('ask') and resource ('Pipeworx'), and distinguishes itself from siblings by naming ask_pipeworx_grounded and deep_research as alternatives for specific use cases.

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

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

The description explicitly says 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', and provides clear guidance on when to use alternatives: use ask_pipeworx_grounded for hallucination-resistant single answers with verbatim evidence, and deep_research for broad/multi-part questions. It also gives concrete query examples, making usage conditions unambiguous.

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 (read-only, idempotent), the description adds critical behavioral context: it is a full working router (not a fallback), and its routing may change dynamically when candidates are under test. It also discloses the current inactive state, preventing surprises.

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

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

The description is moderately sized but well-structured: it front-loads the beta status and equivalence, then explains the experimental edge and usage. Each sentence contributes to understanding, though some redundancy exists (e.g., mentioning identical tools, args, response shape twice).

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 this is a beta variant of an existing tool, the description adequately covers the relationship to ask_pipeworx, the current behavior, and the experimental nature. It doesn't need to explain return values because it explicitly states the response shape is identical to ask_pipeworx.

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

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

The schema already covers all 6 parameters with descriptions, including aliases. The description does not add additional parameter-level meaning, so the baseline score of 3 is appropriate—no deduction or bonus needed.

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

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

The description clearly identifies this as a beta version of ask_pipeworx with the same routing capabilities, using a specific verb ('ask') and resource ('universal router'). It distinguishes from the stable sibling by noting it is experimental, but the core functionality is only implied via the name and reference to 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?

Explicitly states when to use: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also clarifies that it currently matches ask_pipeworx exactly, and mentions that results are compared to decide merges, giving clear context versus the stable 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?

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses key behaviors: routing across 5,462 tools, extraction-only-from-result policy, explicit refusal reasons, and the extra LLM call cost. It even specifies the exact success and refusal response envelopes, going well beyond annotation coverage.

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

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

The description is dense but well-organized: purpose first, then mechanics, return/refusal format, usage context, and trade-off with an alternative. Every sentence contributes meaningful information; no filler or redundancy.

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

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

Given there is no output schema, the description fully specifies the return structure, refusal reasons, and success/error behaviors. It also provides routing context and compares with ask_pipeworx. For a complex tool that routes and extracts, this description is exceptionally 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 schema already documents all six parameters, all as aliases for the question string, with 100% coverage. The description confirms the question is natural language but adds no parameter-specific semantics beyond the schema. Since schema coverage is complete, the baseline of 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 opens with 'Hallucination-resistant answer mode for high-stakes reads,' immediately identifying the tool's specific purpose and differentiator. It further clarifies that it extracts answers only from tool results and returns explicit refusals when data doesn't directly answer, distinguishing it from ask_pipeworx and other siblings.

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

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

Detailed usage guidance is provided: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' followed by concrete examples. It also explicitly says to 'prefer ask_pipeworx for casual lookups' and mentions the extra LLM call cost, giving clear when-to-use and when-not-to-use directives.

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 provide safety hints (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false). The description adds context about what data is returned (names and requirement counts per assurance level), which enhances transparency 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, front-loaded with the core purpose, and no extraneous content. Every sentence justifies its existence.

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

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

Given the tool has no parameters, no output schema, and a simple purpose, the description is complete. It tells what to expect (chapters with names and counts) and how to use the result (to pull with asvs_requirements).

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 and 100% schema description coverage. Per guidelines, baseline is 4 for no parameters. Description adds no parameter information, which is acceptable since there is nothing to document.

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 a table of contents for OWASP ASVS 5.0 with 17 chapters, names, and requirement counts. It also explicitly distinguishes from the sibling tool asvs_requirements by saying to use this to discover which chapter to pull.

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 includes 'Use to discover which chapter to pull with asvs_requirements', which gives clear guidance on when to use this tool. It does not mention when not to use it, but for this simple read-only tool, it is sufficient.

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, destructiveHint. Description adds no contradicting or additional behavioral traits beyond filtering capability, which is acceptable given annotation coverage.

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

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

Two sentences efficiently convey tool purpose, contents, and usage example. Front-loaded with key information, no extraneous text.

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

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

Without output schema, description adequately explains return structure (verification id, section, level, text). Also covers filtering options. Combined with rich annotations and schema, tool is well-specified.

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. Description provides example usage and clarifies enum values (L1/L2/L3) and example id format, but adds limited new meaning beyond schema.

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

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

Description clearly identifies the tool as providing testable security requirements from OWASP ASVS 5.0 with specific fields (verification id, section, level, text). It distinguishes from sibling 'asvs_chapters' by focusing on individual requirements and filtering.

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?

Implies use case for grounding controls ('what does ASVS require for password storage?') and mentions filter options. Does not explicitly state when to avoid or name alternatives, but context is sufficient.

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 is extremely detailed about behavior, including fan-out to data packs, response shapes, safety mechanisms (low-confidence matches, closed markets, wide spreads), and resolution-rule risk. Annotations declare readOnlyHint and idempotentHint, which the description supports with non-contradictory details about how research works.

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 (RESOLVER CONTRACT, SAFETY, etc.). Key info is front-loaded. Every sentence adds necessary detail for a complex tool. Could be condensed, but the length is justified by the tool's sophistication.

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, no output schema, and rich annotations, the description covers all essential aspects: input handling, behavior in edge cases, response shapes, and interpretation of fields like market_match_confidence and parent_event. It leaves almost no ambiguity for agent 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?

Input schema covers all 3 parameters with descriptions. The description adds valuable context: explains market input formats with examples, details the depth parameter's effect via fan-out examples, and explains the include_raw parameter's recommendation. Schema coverage is 100%, so baseline is 3; description adds extra meaning.

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

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

The description explicitly states the tool researches a Polymarket bet by pulling Pipeworx data. It specifies the action (research), resource (bet), and scope, with clear use cases like 'should I bet on X'. This clearly distinguishes it from siblings like polymarket_edges or ask_pipeworx.

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

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

The description provides explicit use cases and examples of input formats (slug, URL, question text). It explains the tool's behavior in different scenarios, though it lacks explicit 'when not to use' instructions. It gives good guidance on when to inspect fields like market_match_confidence and parent_event.

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, open-world, and non-destructive behavior. The description adds valuable context: returning Markdown, handling ambiguous topics with candidate matches, and the all-sheets listing behavior.

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

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

Two efficient sentences with no wasted words. The key behaviors (with/without topic, output format) are front-loaded and clearly communicated.

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

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

Given the tool's simplicity (single optional parameter, no output schema) and detailed annotations, the description fully covers the expected behavior, including edge cases like ambiguity and list mode.

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

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

Schema coverage is 100% with a clear description of the 'topic' parameter. The description adds the nuance of candidate matches for ambiguous topics, but the schema already explains the parameter's purpose and omission behavior.

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

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

The description clearly states the tool returns cheat sheets as Markdown, handling both explicit topics (with ambiguity resolution) and listing all sheets when no topic is provided. This verb-resource pairing is specific and distinguishes it from sibling tools.

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

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

The description provides clear guidance on when to provide a topic (to get a specific sheet) and when to omit it (to list all). It does not explicitly state when not to use, but the context is sufficient for proper usage.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds that it makes one parallel call, results sorted by primary metric, returns paired data + citation URIs, and correctly handles off-calendar fiscal years for companies. This provides rich behavioral context 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 single-paragraph description is densely informative but not verbose. It front-loads trigger phrases and core functionality, then efficiently covers type-specific details, sorting, output notes, and efficiency claim. Every sentence earns its place, with no wasted words.

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

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

Despite moderate complexity (two types, parallel call, sorting, citations), the description covers key aspects: purpose, usage guidelines, behavioral traits, parameter details, and output format (paired data + citation URIs). Annotations provide safety and idempotency context. No output schema needed as description sufficiently explains returns.

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

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

Schema coverage is 100% with descriptions for both parameters. The description enhances these by explaining the data pulled for each 'type' enum value (company: financial data; drug: FAERS, FDA, trial counts) and providing concrete examples for 'values' (tickers/CIKs for company, drug names). This adds significant 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 it performs side-by-side comparison of 2–5 companies or drugs in one parallel call, listing trigger phrases like 'Compare X and Y' and distinguishing between company and drug use cases. It contrasts with single-entity lookups, including a sibling tool 'entity_profile', making purpose unambiguous.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing concrete examples of when to use (comparison phrases) and what it replaces (8–15 sequential lookups). It implies when not to use (single entity lookups) through contrast with entity_profile, offering clear guidance.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description reveals critical behavioral traits: account/payment requirements, latency (15-60s, up to ~90s), parallel decomposition into facets, output structure (gaps[], contradictions[], citation_uri only when resolvable), and semantic excerpting of large records. It clarifies the openWorldHint by explicitly stating it is NOT open-web search, which refines rather than contradicts the 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 long but densely packed with unique, actionable information, front-loading the critical account gate and following a logical flow (account, definition, usage, depth semantics, output details, latency). Some redundancy exists, such as mentioning ask_pipeworx as an alternative three times in different phrasings, which keeps it from a perfect score.

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

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

For a complex tool with no output schema, the description covers virtually all necessary context: authentication, use cases, alternatives, failure behavior (gaps[], contradictions[]), output fields (verbatim evidence, confidence, source, fetched_at, citation_uri), depth modes, latency, and the 'never invented' guarantee. This makes it self-contained enough for an agent to select and invoke correctly.

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

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

The input schema already covers both parameters (100% coverage), providing a baseline of 3. The description enriches the `depth` parameter with paid-tier gating ('depth:"thorough" needs a paid plan') and performance expectations ('Expect 15-60s...'), and adds example questions for `question` ('compare X and Y's regulatory + financial exposure'). This added context goes beyond the schema descriptions.

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

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

The description clearly states the tool's function: 'Grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources... in ONE call' and distinguishes it from siblings like ask_pipeworx ('For a single lookup use ask_pipeworx') and open-web search ('this is NOT open-web search'). The verb+resource+output structure is explicit and unambiguous.

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

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

Provides explicit when-to-use ('Best for broad/multi-part questions over structured data') and when-not-to-use ('For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'), including the alternative tool name and even a sign-in prerequisite ('If you are not signed in, use ask_pipeworx instead'). It also gives concrete example questions and notes the fallback behavior of empty gaps[] for non-structured topics.

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

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

The description adds significant behavioral context beyond annotations: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' This explains output structure and reusability. Annotations already declare read-only and idempotent, and description is consistent.

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

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

The description is a single paragraph that front-loads purpose and lists domains, but it is somewhat verbose. It could be more concise by removing redundant phrases like 'full input schemas' since schema is implied. Every sentence earns its place but could be tightened.

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

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

For a tool with 6 parameters (mostly aliases), no output schema, and simple structure, the description covers purpose, return value, and usage context. It does not discuss error handling or rate limits, but annotations (readOnly, idempotent) fill gaps. Overall, it is sufficiently complete for an AI agent.

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

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

Schema coverage is 100% with 6 parameters all described. The description adds usage examples (e.g., 'analyze housing market trends') which provide context but do not significantly extend schema descriptions. Baseline 3 is appropriate as schema already documents parameters thoroughly.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists numerous specific domains (SEC filings, FDA, etc.) and states it returns top-N tools with schemas. This differentiates it from siblings like search_within or deep_research by focusing on tool discovery rather than data 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 explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It provides clear context for when to use, though it doesn't explicitly list when not to use or name specific alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: it fans out across multiple sources in parallel, notes that the patents API soft-fails after May 2025, and details returned fields. No contradictions.

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

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

The description is relatively long but every sentence adds value, providing examples, usage guidance, and detailed return structure. It is front-loaded with purpose and immediately followed by usage directions. Some minor redundancy could be trimmed.

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

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

Given no output schema, the description thoroughly explains return values including cik, company_name, recent_filings with URIs, fundamentals sorted by period_end, patents with sunset note, news, and LEI. Two required parameters are fully covered. The description leaves little ambiguity.

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

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

Schema coverage is 100%. The description adds meaning beyond the schema: it clarifies that value accepts ticker or zero-padded CIK, explicitly states names are not supported, and mentions resolve_entity as a prerequisite. It also explains the type parameter's current limitation to 'company'.

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

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

The description explicitly states the tool provides a 'full cross-source profile of a US public company in ONE parallel call', listing specific data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and return fields. It distinguishes itself from sibling tools like resolve_entity by noting when to use each.

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 guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also specifies that names are not supported and directs users to use resolve_entity first. Example queries are provided.

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. Description adds 'Delete' but no further behavioral context such as confirmation, error handling, or effect on related data.

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

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

Two concise sentences with front-loaded purpose and usage guidance. No unnecessary words.

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

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

Covers purpose, usage, and basic behavior adequately for a single-parameter tool with annotations. Lacks mention of return value or error conditions.

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?

100% schema coverage; description does not add meaning beyond the schema's description of the 'key' parameter. Baseline score.

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

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

Clear verb 'Delete' and specific resource 'previously stored memory by key'. Distinguishes from siblings 'remember' and 'recall' by referencing them.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also suggests pairing with 'remember' and 'recall'.

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 as false. The description adds valuable behavioral details: fetches the page, extracts title/description/key links, emits standard markdown. It explains the output format ('single text blob') without contradicting annotations.

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

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

The description is concise, front-loaded with the main action, and efficiently covers process and use cases in a single paragraph. No redundant sentences.

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

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

Given no output schema, the description adequately describes the output as a text blob ready for deployment. With only two parameters and clear workflow, it is complete and sufficient for an agent to use correctly.

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

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

Schema has 100% coverage for both parameters with descriptions. The description does not add significant extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: generate an llms.txt file for any URL. It specifies the verb (generate), resource (llms.txt file), and context (AI crawlers). It also distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on file generation.

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

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

The description provides explicit use cases (client indexing, own project, competitor auditing) but does not mention when to avoid using it or alternative sibling tools. The examples are helpful but exclusions are missing.

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, destructiveHint. Description adds return fields and parameter implication but no additional 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 front-loaded with purpose. 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?

For a simple tool with one optional param and no output schema, description covers purpose, return fields, and usage. Could mention caller-scoped filtering explicitly.

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 full description of include_inactive. Description implicitly references active-only default but does not add meaning beyond schema.

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

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

Description clearly states 'List the caller's active subscriptions' with specific verb and resource, and lists return fields. Distinguishes from siblings like subscribe/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?

Explicitly states when to use ('review before adding more', 'find id to cancel'), providing clear context. Does not mention alternatives but contextually differentiated from siblings.

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

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

Beyond the sparse annotations (all false hints), the description discloses important behavioral details: rate limiting (5 per identifier per day), that it's free and doesn't count against the call quota, how the team processes feedback (digests affect roadmap), and a caution not to paste end-user prompts. This fully covers the burden given the minimal 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?

Although the description is wordy, every sentence carries essential information: purpose, usage triggers, exclusions, constraints, rate limits, and content guidance. It's structured logically, starting with the core function and expanding to details, without 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?

With three parameters, no output schema, and non-informative annotations, the description fully compensates: it covers purpose, alternative tools, exclusions, rate limits, quota impact, and content expectations. The nested context object is adequately explained in the schema, and the description provides all necessary context for a feedback tool.

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

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

The schema already describes all parameters with 100% coverage, so baseline is 3. The description adds value by instructing users to describe issues in terms of Pipeworx tools/packs rather than pasting end-user prompts, which gives practical guidance on message content beyond the schema. However, this is incremental, not transformative.

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: sending feedback to the Pipeworx team about broken, missing, or desirable features. It enumerates specific feedback types (bug, feature, data_gap, praise) which distinguishes it from sibling tools and leaves no ambiguity about what the tool does.

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

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

The description explicitly defines when to use the tool (for bugs, feature requests, data gaps, praise) and when not to use it (if the tool belongs to a different MCP server). It also tells users to file feedback with the appropriate server, providing clear exclusions and alternatives.

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

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable behavioral context: data source ('CF analytics-engine'), privacy ('no PII'), caching ('5min-1h depending on window'). 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 well-structured paragraphs. First sentence front-loads purpose. Use cases bulleted. Every sentence adds value. No redundant information.

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

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

For a read-only tool with one optional parameter and good annotations, the description covers purpose, use cases, data source, privacy, caching. No output schema, but return values are described. Minor gap: does not specify format of returned data (e.g., list, JSON), but still adequate.

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

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

Schema covers 100% of parameters with enum descriptions. Description adds value by explaining the effect of window choice on hotness vs. steady-state demand. More than 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 returns top tools, top packs, and total call volume over a window. It uses specific verbs ('returns') and resource ('what other AI agents are calling on Pipeworx'). Distinguished from siblings by focusing on aggregate trends rather than individual queries or entities.

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

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

Explicitly lists three use cases (discovering hot data sources, confirming popular tool, seeing alignment). Provides guidance on window selection ('Shorter windows surface what's hot right now'). Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations declare readOnlyHint=true, and the description adds extensive behavioral detail: partition_check logic, semantic anchor, partition filter, fill check, and dangerous signals. 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?

Well-structured with front-loaded summary, then args, then details. Slightly lengthy but all information is pertinent. Could be trimmed slightly but justified for complexity.

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

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

Covers all necessary aspects: modes, internal algorithms, response structure, fill check, and references related tool. No output schema exists, but description details return fields adequately.

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

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

Schema already describes parameters (100% coverage). Description enhances by explaining acceptable slugs, full URLs, seed questions, and mode implications. Adds valuable context beyond schema.

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

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

The description states 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks', providing a specific verb, resource, and method. It clearly distinguishes from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicitly explains when to use no args (trending_scan), event mode (single-market), and topic mode (cross-event). Recommends event for specific markets, describes cross-event benefits, and warns against trading when fill check fails.

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 annotations (readOnlyHint, idempotentHint, etc.) by detailing the model families, edge calculation, Kelly fractions, slippage assumptions, caching behavior, and response structure. There is no contradiction with annotations.

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

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

The description is a dense block of text that lacks structural elements like bullet points or section breaks. While it is front-loaded with a clear purpose sentence, the subsequent detailed model descriptions could be more concise or organized for easier consumption by an AI agent.

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

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

Given the complexity (9 parameters, multiple segments, no output schema), the description provides comprehensive details on response structure, edge calculation, filtering knobs, and diagnostics. It fully explains what the tool returns and how to interpret results.

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

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

All 9 parameters have descriptions in the input schema (100% coverage), so the schema already provides sufficient meaning. The tool description adds some context about knobs like min_liquidity and max_spread_pp, but this is marginal and could be inferred from 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 scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, and it mentions 'what should I bet on today' as the use case. However, it does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_edge_tracker, leaving some ambiguity about when to choose this over those alternatives.

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

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

The description provides context on the three segments (model_driven, structural_arbitrage, concentrated_longshot) and explains when each might apply. It also mentions that Fed bets are excluded from ranking. However, it does not offer explicit guidance on when not to use this tool or recommend alternatives from the sibling list.

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, and the description adds significant behavioral context: history bounded by 60-day TTL, decay from daily closes not intraday, and snapshot gaps meaning no scan. 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 verbose but well-structured with RESPONSE sections. Every sentence adds value, though some could be trimmed (e.g., parenthetical asides). Front-loads the core purpose effectively.

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

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

With no output schema, the description fully explains the three response arrays (tracked, expired, snapshot_dates) with field details and semantics. Also covers edge cases like snapshot gaps and TTL limits, making the tool usage 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 already describes both parameters (days, window) with types and descriptions. The description adds defaults (14, '1wk') and clamps (days 2-30, window options). This goes beyond the schema, providing essential operational details.

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 verb 'edge persistence and decay telemetry' and resource 'daily polymarket_edges snapshots'. It clearly distinguishes from sibling tools like polymarket_edges by focusing on the time-series aspect (how long an edge has existed).

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

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

The description explains when to use this tool (to check edge age and decay), but does not explicitly state when not to use it or compare with alternatives like polymarket_edges for single-snapshot analysis. The context is clear but lacks exclusionary guidance.

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

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

Description details operational behavior: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, etc.), warns about risks of thin books and partial fills. Annotations (readOnly, idempotent, non-destructive) align with the description; no contradictions.

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

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

The description is dense and well-structured with uppercase cues and bullet-like lists. While somewhat verbose, every sentence adds value. Slightly more conciseness could improve scannability.

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, no output schema), the description is remarkably complete. It explains return fields, warnings about thin legs and directional risk, and when to use. Leaves no critical gap for an agent to understand the tool.

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

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

Schema coverage is 100%, but the description adds crucial context beyond schema: explains requirement of market or event, default behavior for side, interpretation of size_usd in basket mode, and clamping range. This significantly aids correct parameter 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?

The description clearly states the tool performs a realizable-vs-theoretical edge check against live order-book depth. It specifies two modes (single-market and basket) and distinguishes from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Also explains why partial basket fills are risky, giving clear when-to-use and when-not-to-use advice.

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 safe, read-only, non-destructive behavior. The description adds substantial context: compatibility_warning cases, temporal_alignment field, skipped_cross counters, and that real spreads are rare. 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 and front-loaded with core purpose. Each sentence adds value, though slightly verbose. The safety fields are clearly separated.

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 3 optional parameters, no required params, no output schema, and many siblings, the description is very complete. It explains edge cases, both modes, and output fields thoroughly. Schema includes examples.

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 schema by explaining the two modes, topic shortcuts, explicit override, and the meaning of output fields (top_spreads_pp, compatibility_warning, etc.), compensating for missing output 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 computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It specifies two modes (topic and explicit tickers) and distinguishes it from sibling tools like polymarket_arbitrage.

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

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

The description provides explicit when-to-use guidance (compare prices across venues) and warns about when not to use (temporal misalignment, metric type mismatch, most pre-mapped topics not tradeable). It does not directly name alternatives but context implies this is for cross-venue spreads.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds scoping and pairing context. No contradictions.

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

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

Two sentences, front-loaded with function, no wasted words. Efficient and clear.

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 simple tool with one optional param and rich annotations, description fully covers use cases, scoping, and pairing. No gaps.

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

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

Schema has 100% coverage for the single parameter. Description repeats similar info but adds context about origin of stored values. 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?

Clearly states it retrieves a saved value or lists all keys. Distinguishes from siblings '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?

Provides clear examples of when to use (look up stored context) and mentions pairing with other tools. Lacks explicit when-not-to-use, but context is sufficient.

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 explains mark_read:true flags events as read, modifying state, yet annotations declare readOnlyHint=true. This is a direct contradiction between described write-side effect and read-only hint.

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

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

Four sentences, front-loaded with purpose, no redundancy. Every sentence adds meaningful context.

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

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

Clearly states returned fields (source, citation_uri, payload) and usage context. Lacks output schema but description compensates. Minor gap: no mention of feed persistence semantics.

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, description adds value beyond schema by explaining mark_read effects on subsequent calls and providing defaults (limit=50, mark_read=false).

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

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

The description clearly states the tool pulls fired events from a subscription feed and specifies returned fields. However, it does not explicitly differentiate from sibling tools like list_subscriptions or subscribe.

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

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

Provides filtering options (type, since) and explains mark_read behavior for efficient polling. Mentions alternative access via GET endpoint but lacks explicit when-not-to-use guidance.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: fans out to three sources, fallback logic, date format parsing, return structure with grouped changes and citation URIs. No contradiction with annotations.

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

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

The description is a single paragraph but efficiently front-loads with user query examples and then details mechanics. Every sentence adds value: examples, sources, fallback, date formats, return format, and cross-reference to sibling. 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?

For a tool with no output schema, the description fully explains the return value: 'structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs'. It also covers complexity of multiple data sources, fallback, and date parsing.

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

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

Schema coverage is 100% with descriptions for each parameter. The description adds meaning: explains 'since' accepts ISO date or relative shorthand (with examples), 'value' can be ticker or CIK, and 'type' is limited to 'company'.

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 in the last N days/weeks/months, fanning out to SEC EDGAR, GDELT/GNews, and USPTO. It distinguishes from the sibling tool 'entity_profile' by noting 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?

Provides explicit guidance on when to use this tool versus 'entity_profile', and gives specific query examples like 'What's new with X' and 'latest on Y'. It also describes fallback behavior (GDELT to GNews) and limitations (USPTO soft-fail).

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 idempotentHint=true and destructiveHint=false, but the description adds valuable context: key-value pairs scoped by identifier, persistent for authenticated users, and 24-hour retention for anonymous sessions. 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?

Four sentences, front-loaded with action, each sentence adds essential information: purpose, usage context, persistence details, and companion tools. No fluff 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?

The description covers core functionality and persistence context, but lacks mention of return values or success confirmation, which would be helpful for a write operation without an output schema. However, the tool is simple and the idempotent hint mitigates some uncertainty.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the scoping mechanism (by your identifier) and naming conventions (e.g., subject_property), which go beyond the parameter descriptions.

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

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

The description starts with a clear verb+resource: 'Save data the agent will need to reuse later.' It distinguishes from sibling tools like recall and forget by explicitly mentioning pairing with them. The scope 'across this conversation or across sessions' adds specificity.

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

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

The description advises when to use: 'when you discover something worth carrying forward... so you don't have to look it up again.' It also mentions recall and forget as companion tools. However, it does not explicitly state when not to use (e.g., for transient data), leaving room for slight ambiguity.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond that: internal cascading through multiple lookup endpoints, auto-disambiguation, and citation URIs returned. This gives the agent a better sense of the tool's execution and output characteristics.

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 somewhat long. It opens with example queries, then includes supported types, return fields, and an internal behavior note. Each sentence serves a purpose, but the description could be tightened slightly without losing value. Front-loading is good.

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 two-parameter tool with no output schema, the description covers return values for both entity types (ticker, CIK, company name, citation URI for company; RxCUI, ingredient, brand, citation URI for drug), plus auto-disambiguation and internal cascade. This gives the agent a solid understanding of what to expect, though it omits potential error cases or format nuances.

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

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

The input schema has full coverage (100%) with detailed descriptions for both parameters, including the value format per entity type. The description repeats the same formats and adds examples, but does not add significant new parameter-level meaning beyond what the schema already provides. Thus the baseline 3 is appropriate.

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

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

The description clearly states the tool resolves user-spoken names to canonical identifiers, with specific verbs ('resolve', 'look up') and resource types (company, drug). It distinguishes itself as the go-to tool when an ID is needed, and provides concrete examples of query phrases, making its purpose unmistakable.

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

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

The description explicitly instructs 'Use FIRST whenever you have a name but need an ID,' which gives strong contextual guidance. It also notes that the tool replaces multiple manual lookups. However, it does not explicitly mention when not to use it or name specific alternative tools, so it does not fully meet the 'when-not' criterion.

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=false. The description adds behavioral details: probes each entity with ai_visibility_check, ranks by score, surfaces most/least recognized, returns ranked list with score, confidence, signal density. This provides useful context beyond annotations.

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

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

Two sentences: first states action and process, second provides a concrete usage example. Every sentence is purposeful, no filler. Front-loaded with key information.

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

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

Given the tool complexity (multi-entity comparison, ranking) and no output schema, the description adequately describes the return format (ranked list with score, confidence, signal density). It references the probing mechanism via ai_visibility_check, which is sufficient for an agent to understand the tool's behavior without excessive detail.

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 parameters have descriptions. The description adds value by noting that the first entity is treated as the 'subject' for narrative and rest as competitors, which is not in the schema. However, it does not elaborate on the 'models' parameter options or the _apiKey usage beyond what's in the schema.

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

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

The description uses specific verb+resource ('Compare AI visibility across multiple entities side-by-side') and clearly distinguishes from sibling 'ai_visibility_check' by being a multi-entity comparison. It states what it does, how it works (probes with ai_visibility_check, ranks), and what it returns.

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

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

The description provides explicit usage context: 'Useful for competitive AI-marketing audits: "does Claude know about us as well as our competitors?"'. It implicitly distinguishes from single-entity probe, but does not explicitly state when not to use or 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. Description adds behavioral details: partial failures degrade gracefully, bundlephobia's first measurement may take 5-30s, sources_failed field. 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?

Description is dense but front-loaded with purpose and usage. Every sentence contributes value, though length could be slightly trimmed for conciseness.

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

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

Despite no output schema, description lists returned fields, explains partial failure behavior, and covers key behavioral aspects. For a composite tool with two params, it is highly complete.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds nuance: scoped packages accepted for 'package', default to latest version for 'version'. Adds value beyond schema.

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

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

Description uses specific verbs ('scan', 'check') and resource ('npm package dependency') and clearly distinguishes from siblings by focusing on npm ecosystem and composite checks across multiple sources.

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 whenever an agent asks 'is X safe / popular / small''. Provides ecosystem limitation: 'NPM ecosystem only in v1' and alternative tools for other ecosystems. Lacks explicit when-not-to-use but guidance 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 goes well beyond the annotations (readOnly, openWorld, idempotent) by disclosing the underlying embedding model (BGE-base-en), chunking method (500-char overlapping windows), similarity metric (cosine), character limit (200K chars with truncation and flagging), and that every passage carries an offset for quote verification. No contradictions.

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

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

The description is front-loaded with the core purpose, then provides usage guidance, pairing advice, and technical details in sequence. Every sentence is informative with no redundancy or filler. It is compact yet comprehensive.

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

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

Given the tool's complexity (3 parameters, no output schema, no nested objects), the description covers what the tool does, when to use it, how it works internally, limitations (200K chars), and return format (passages with offsets and scores). It sufficiently equips an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with good descriptions already. The description adds value by providing examples for the query parameter, clarifying the max character length for text, and explaining the truncation behavior. This additional context aids the agent in using the parameters effectively.

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

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

The description clearly states the tool performs semantic search inside a fetched record, gives concrete examples (SEC 10-K, article, long tool result), and distinguishes itself from the sibling ask_pipeworx_grounded by stating they pair together. The verb 'search' with 'inside a fetched record' is specific and unambiguous.

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

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

It explicitly says when to use: 'when the record is too big to cram into the prompt' and explains that it saves context and returns only relevant passages with offsets. It mentions pairing with ask_pipeworx_grounded but does not explicitly state when not to use or list alternatives beyond that.

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

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

The description adds significant behavioral context beyond annotations: it details auth requirements (Pipeworx OAuth account), delivery channel specifics (feed always on, optional email/sms/webhook), limitations (10 SMS/day, webhook auto-disable after 10 failures), and idempotency implications. 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 thorough but slightly verbose. It is well-structured with purpose first, then auth, types, and delivery. Each sentence adds value, but some details (e.g., webhook signature verification) 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 (multiple types, optional delivery channels, auth requirements), the description covers prerequisites, type-specific params, delivery limits, and return value. No output schema is needed as the return (subscription id) is stated.

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 enriches each parameter with concrete examples and constraints. For 'type', it lists examples per value. For 'params', it provides type-specific JSON structures. For 'delivery', it explains SMS verification, email templating, and webhook HMAC signing.

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

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

The description clearly states the action (Create a proactive monitoring subscription), the resource (live-data event stream), and the return value (new subscription id). It distinguishes from siblings like list_subscriptions, unsubscribe, and recent_alerts.

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

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

The description explains when to use this tool (proactive monitoring), outlines supported types and delivery channels, and provides prerequisites (Pipeworx OAuth account). However, it does not explicitly state when not to use it or compare directly to alternative 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 read-only, open-world, idempotent, non-destructive. Description adds that it returns example questions with exact tool+argument shapes from a live catalog, which is valuable 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 fairly long but front-loaded with common user queries and structured clearly. Every sentence adds value, though some minor redundancy could be trimmed.

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

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

Given the tool's simplicity (one optional param, no output schema), the description fully covers its purpose, usage, and behavior. Annotations provide safety guarantees, making the description complete.

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

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

Schema coverage is 100% and the description reinforces the parameter's purpose and provides example values. It adds useful examples but does not significantly extend beyond the schema description.

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

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

The description states a specific verb 'returns category-bucketed example questions' and distinguishes from siblings by positioning it as the onboarding entry point to be used first, versus other tools like ask_pipeworx.

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

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

Explicitly says to use this FIRST when you don't know what Pipeworx can do, and provides instructions for calling with no arguments or passing a topic. Contrasts with meta-tools mentioned in the description.

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, covering safety traits. The description adds that the tool returns canonical URLs and is for awareness, but does not disclose additional 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?

The description is two sentences, front-loaded with content and purpose, and no wasted words. It efficiently conveys all necessary 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 tool with one optional parameter and no output schema, the description covers what the tool returns (id, name, summary, URL) and appropriate use cases, making it fully 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 input schema has 100% coverage with one enum parameter described as 'Which Top 10 (default "web").' The description adds the specific years for each list (e.g., 'web' 2021) and mentions defaults beyond the schema, providing meaningful context.

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

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

The description clearly states it provides OWASP Top 10 lists for web, API, LLM, and mobile, each with id, name, summary, and URL. It distinguishes itself from siblings by its specific topic and use cases.

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

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

The description explicitly says 'Use for awareness, mapping a finding to a category, or LLM-app threat modeling,' providing clear context. It does not explicitly mention when not to use, but the narrow scope and unique offering make implicit sense.

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

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

Discloses that the row is deactivated, not deleted, ensuring historical events remain via recent_alerts. Annotations already indicate non-destructive, but description adds valuable detail 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 with no redundant information. Immediately states the core purpose and adds critical behavioral details without fluff.

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

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

For a simple tool with one parameter and no output schema, the description covers all necessary aspects: action, ownership, and side effect (deactivation). No gaps.

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

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

The description adds context to the 'id' parameter by noting it is 'returned by subscribe', which enhances schema coverage (100% already) with usage hint.

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

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

Clearly states the action 'Cancel a subscription by id.' with a specific verb and resource, distinguishing it from siblings like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly mentions ownership enforcement, indicating when the tool can be used (only for own subscriptions). No alternatives mentioned, but context is clear.

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

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

The description adds significant behavioral context beyond annotations: it explains the two verification pathways (SEC EDGAR+XBRL vs grounded pipeline), mentions the verdict types, cites evidence with pipeworx:// URLs, and notes efficiency gains. No contradiction with annotations (readOnly, openWorld, idempotent).

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

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

The description is moderately long but well-structured: starts with example invocations, then explains mechanics, then return format. Every sentence adds value, though slight tightening could improve conciseness.

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

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

Despite no output schema, the description fully specifies the return values: verdict type (with enumerated options), value with citation, and reasoning. It also covers edge cases like company-financial vs other claims. Complete for a tool of this 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%, but the description adds valuable context: for 'tolerance_pct' it explains override behavior and provides a concrete use case (hallucination detection). For 'claim' it reinforces the natural-language nature. This extra guidance justifies above-baseline score.

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

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

The description clearly states the tool's purpose: 'natural-language claim verification against authoritative sources.' It provides example queries and distinguishes between company-financial and other claims, making the function specific and actionable.

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 whenever the agent needs to check whether something a user said is factually correct.' This is clear guidance on when to use. However, it does not explicitly differentiate from sibling tools like ask_pipeworx_grounded or deep_research, missing opportunities to clarify when not to use.

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