Password

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the default model is free, passing _apiKey invokes Anthropic with direct billing to the user, and the return structure includes per-model signals and raw_response. This is important cost and data-usage transparency not conveyed by annotations.

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

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

The description is three sentences: front-loaded with the main action, followed by key operational details (default model, API key handling) and use cases. Every sentence contributes value, with no fluff or repetition.

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

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

Despite lacking an output schema, the description explains the return shape (per-model {score, confidence, signals, raw_response} + combined view). Combined with 100% schema coverage and rich annotations, this provides sufficient context for selection and invocation. No critical behavioral details are missing.

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

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

Schema covers all 4 parameters with descriptions, so baseline is 3. The description adds semantics beyond the schema by explaining the default model (Workers AI Llama-3.3-70b free) and clarifying the cost relationship when passing _apiKey. This enriches the model selection parameter's 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 uses a specific verb ('Probe') and resource ('one or more LLMs') and clearly states the output (visibility score 0-100 per model). It distinguishes itself from siblings like scan_competitor_ai_presence and compare_entities by focusing on probing LLM knowledge for any entity and scoring it.

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

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

The description provides clear use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') which imply when to use the tool. However, it does not explicitly name alternatives or exclusions, so it lacks the explicit 'when-not' guidance that would merit a 5.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint all non-conflicting. The description adds behavioral context beyond annotations: it is a router, performs 'one fast call', works on every tier, and returns citations. While it doesn't cover failure modes or latency extremes, it meaningfully describes the tool's operational 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?

The description is long but well-structured and front-loaded with the most important directive ('PREFER OVER WEB SEARCH'). Each sentence adds value: domain listing, routing semantics, usage triggers, examples, and escalation paths. Length is justified for a multi-tool router, though it could be tightened slightly without losing essential info.

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 explains return values: 'structured answer with stable pipeworx:// citation URIs'. It covers domain coverage, trigger examples, alternatives, and scope details (works on every tier, one fast call). For a tool with a huge potential scope, this is sufficiently complete to guide correct 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?

Schema coverage is 100% and the schema already documents the 'question' parameter with alias descriptions. The description adds examples and clarifies natural language input, but the schema does the heavy lifting. This matches the baseline 3 per the rubric; the description provides only marginal extra value.

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

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

The description clearly states the tool's purpose: it routes questions to 5,439 tools across 1,412 verified sources and returns structured answers with stable pipeworx:// citation URIs. It enumerates specific domains (SEC filings, FDA drug data, FRED/BLS, etc.), distinguishing it from generic web search and sibling tools like ask_pipeworx_grounded and deep_research.

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

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

It provides explicit when-to-use guidance: 'PREFER OVER WEB SEARCH', 'Use whenever the user asks...' with trigger phrases, and 'START HERE for most questions'. It also states when not to use it and names alternatives: use ask_pipeworx_grounded for hallucination-resistant single answers, use deep_research for broad/multi-part questions, and for breaking news it clarifies that ask_pipeworx already routes to live news.

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

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

The description discloses substantial behavioral traits beyond the annotations: it may have routing improvements enabled live whenever one is under test, currently matches ask_pipeworx because no candidate is active, and is a full working router with no fallback. It also states that queries are compared against the stable router, providing important transparency about how input is used.

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 front-loaded sentences convey the beta nature, current state, usage, and behavioral expectations without waste. Specific details like 5,439 tools and the retirement date are purposeful and enhance clarity.

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

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

The description is complete for an experimental variant, covering current behavior, usage, and relation to the stable router. However, it relies on the reader knowing what ask_pipeworx is and does not describe the response format beyond saying it shares the same shape, which is a minor gap given no output schema.

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 question plus aliases fully described. The description only says 'same arguments' as ask_pipeworx and adds no meaningful semantic detail beyond the schema, so baseline 3 is appropriate.

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

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

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

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 tells the agent to use it exactly like ask_pipeworx when wanting the newest routing, and notes that results are compared against the stable router to decide merges. It implies the stable ask_pipeworx as an alternative but does not explicitly state when not to use this beta or mention other sibling 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?

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses the refusal behavior with specific refusal_reason enum values, the return structure including evidence and confidence, and the cost of one extra LLM call. This gives the agent a precise model of what will happen, especially important because no output schema is provided.

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

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

The description is dense but every sentence earns its place: purpose, mechanism, return contract, refusal reasons, usage guidance, and cost/alternative. It is front-loaded with the core value proposition, and the structured list of refusal reasons is efficiently embedded rather than padded.

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

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

Given the absence of an output schema, the description fully specifies the return format and refusal semantics. It covers the routing mechanism, the groundness guarantee, when to use, and the trade-off versus the sibling tool. The parameter schema is exhaustive, and the tool's complexity is well matched by the description's 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 description coverage is 100%: all six parameters are documented as aliases for 'question', with the canonical 'question' param described as 'Your question in natural language.' The tool description adds no additional parameter semantics 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 is a 'hallucination-resistant answer mode for high-stakes reads' and explains the exact process: routing, fetching data, then extracting the answer using only the tool result. It distinguishes itself from the sibling ask_pipeworx by emphasizing the grounded extraction and refusal behavior.

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

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

Explicitly states when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete examples (financial verdicts, legal claims, medical lookups, public statements). Also gives an exclusion: 'prefer ask_pipeworx for casual lookups' due to the extra LLM call cost, making the decision clear.

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

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

Annotations already declare readOnly=true, openWorld=true, idempotent=true, destructive=false. The description goes far beyond, disclosing resolver match confidence semantics, parent_event extraction, news fallback behavior (_fallback_attempted), closed-market statuses, wide-spread illiquidity warnings, and cancellation-rule risk (refund_50_50, etc.). It even quantifies the recurring flat-50¢ void settlement loss, adding serious operational context.

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

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

The description is lengthy, but every section earns its place. It is front-loaded with the core purpose, then logically organized into labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, NEWS FIELDS, SAFETY, RESOLUTION-RULE RISK). It is appropriately sized for a tool with no output schema and complex behavior.

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

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

With no output schema, the description must document return shapes and it does thoroughly: market fields, analysis fields, evidence keying, resolver contract, parent_event, news fallback, statuses, and safety mechanisms. It covers edge cases (low-confidence, closed markets, wide spreads) and provides operational warnings (cancellation rule risk), making it fully complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reaffirms the market input format and provides concrete fan-out examples, but it does not add materially beyond the schema's parameter descriptions (e.g., depth, include_raw). It adds illustrative context but not new parameter meaning.

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

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

The description opens with a specific verb+resource+mechanism: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It clearly distinguishes from siblings by focusing on research/synthesis rather than raw market data, arbitrage, or edge detection. Use-case examples ('should I bet on X') reinforce the purpose.

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 for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' However, it does not name alternative tools or conditions where it should NOT be used, so it lacks the explicit exclusion/alternative guidance needed for a 5.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses critical behavioral traits: the password is processed entirely in-process without transmission or storage, and the analysis is heuristic rather than a guaranteed assessment. These details significantly aid the agent in understanding side effects and limitations, exceeding what annotations alone provide.

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

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

Two sentences, front-loaded with the primary action and outcome. The first sentence lists all outputs and key constraints; the second addresses privacy and caveats. Every word earns its place, with no redundancy or filler.

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

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

For a single-parameter tool with rich annotations, the description is self-sufficient. It covers inputs, outputs, execution context (offline, in-process), and limitations (heuristic). No output schema exists, but the description enumerates what the agent can expect, making the tool's behavior fully predictable.

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 fully describes the single parameter ('The password to analyze.') with 100% coverage. The description adds context about how the password is used (entropy, crack time, weaknesses), but does not add format constraints or example values beyond the schema's examples. This is a simple parameter, and the baseline of 3 applies because the schema carries the structural meaning while the description enriches the purpose.

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 begins with a specific verb and resource: 'Analyze a password's strength offline'. It enumerates concrete outputs (character-set entropy, strength rating, crack time, weaknesses) and clearly distinguishes itself from sibling tools by focusing on offline password analysis. This 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 provides clear context for when the tool is appropriate: offline, keyless, privacy-preserving analysis ('password is NOT transmitted or stored'). It implicitly signals alternatives are not needed for this niche, but it does not explicitly state exclusions or name alternative tools. Absence of explicit alternatives is offset by the tool's unique purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds substantial behavioral context: data sources (SEC EDGAR/XBRL, FAERS/FDA), off-calendar fiscal year handling, sorting by primary metric, citation URIs, and performance benefit. This goes well 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 lengthy but each sentence delivers unique value: trigger phrases, operation, type-specific details, sorting, citations, and performance comparison. It is front-loaded and structured, though slightly verbose; a minor deduction for density.

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

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

Given no output schema, the description explains return format (paired data + citation URIs), ordering, data sources, and fiscal-year correctness. It fully covers the tool's behavior for both entity types, making it self-sufficient for an 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 describes type and values with examples, but description adds deep meaning: type='company' pulls specific 10-K metrics, type='drug' pulls FAERS/FDA/trial counts, and values are elaborated as 2–5 tickers/CIKs or drug names. This enriches parameter understanding beyond the schema.

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

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

The description clearly defines the tool as a side-by-side comparison of 2–5 companies or drugs in one parallel call, with explicit trigger phrase examples like 'X vs Y' and 'rank these companies'. It distinguishes itself from sibling tools like entity_profile by stating 'ALWAYS PREFER over sequential single-pack lookups'.

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

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

It explicitly states when to use the tool: whenever comparing entities, and identifies the alternative of sequential single-pack lookups. It also clarifies the two entity types and what each returns, guiding correct selection.

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

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

Beyond annotations (readOnly, openWorld, idempotent), the description adds extensive behavioral context: account requirements, latency ranges (15-60s, up to ~90s for thorough), return packet structure (findings with evidence, confidence, source, fetched_at, pipeworx:// citations), explicit gaps[] handling (never invented), contradictions[] for deeper depths, and semantic excerpting of large records. It also warns about empty results for unsupported topics, and explains hop behavior for gap recovery.

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

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

The description is long but every sentence conveys a distinct and useful fact. It is logically structured: prerequisites, use cases, alternatives, operational behavior, return format, and performance expectations. While verbose, the complexity of the tool (depth levels, hop mechanics, citation formats) justifies the length; it avoids redundancy.

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

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

Given the tool's complexity and lack of output schema, the description thoroughly explains the return packet (verbatim evidence, confidence, source, fetched_at, citations, gaps[], contradictions[], hop field), account requirements, depth variations, and expected latency. It covers edge cases like unsupported topics returning mostly empty gaps and the distinction between record-level and source-level citations, making it complete for an 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?

The schema already describes both parameters (question and depth) with detail, giving full coverage, so baseline is 3. The description adds semantic nuance beyond the schema by explaining how depth levels change behavior ('quick=3', 'standard adds gap-recovery hop + contradictions scan', 'thorough adds iterative hop') and that broad/multi-part questions are fine, which enriches agent decision-making.

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 'Grounded multi-source research... in ONE call' across structured data sources, with examples of broad/multi-part questions. It distinguishes itself from sibling tools like ask_pipeworx by explicitly labeling itself 'NOT open-web search' and contrasting its use case for single lookups.

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

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

The description explicitly states when to use this tool ('Best for broad/multi-part questions over structured data') and when not to ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS topics, prefer ask_pipeworx'). It also gives account tier prerequisites, including a paid plan for 'thorough' depth.

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 idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: results include 'full input schemas (with curated examples)' and are 'ready to call directly, no second schema lookup needed,' which explains the output behavior and reduces uncertainty for the agent.

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

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

The description is well-structured and front-loaded: purpose in the first sentence, domain coverage in the second, return behavior in the third, and usage guidance in the fourth. No wasted words; the domain list is relevant and informative.

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

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

Despite having no output schema, the description fully explains what the tool returns (names, descriptions, schemas, curated examples) and how to invoke it. It is complete for a read-only discovery tool with clear annotations and simple parameters.

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% (every parameter including aliases has a description), so the baseline is 3. The description reinforces that the query is a natural-language description but adds no new parameter-level semantic detail beyond the schema. The mention of 'top-N' relates to the limit parameter but is already described 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 clearly states a specific verb and resource: 'Find tools by describing the data or task.' It also enumerates the covered domains and explicitly describes the return value (top-N tools with names, descriptions, and full input schemas), distinguishing it from sibling tools that perform direct lookups or analysis.

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

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

The description provides clear context on when to use: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It does not explicitly name alternatives or state when-not-to-use, but the 'FIRST' guidance implies priority over other 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?

The description adds significant behavioral detail beyond the annotations: it fans out across multiple sources, returns specific fields, soft-fails for patents after the USPTO API sunset, uses a GDELT→GNews fallback, and requires ticker/CIK input. This is useful context that the readOnly/idempotent hints do not convey. No contradiction with annotations.

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

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

The description is dense but well-organized, using examples up front and semicolon-separated output fields. It is longer than average, but every segment adds value. It could be slightly more scannable, but it earns its length given the tool's 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?

With no output schema, the description fully enumerates the return fields and their sources. It also covers constraints (US only, patent sunset, names not supported) and fallback behavior. The tool is complex, and the description provides sufficient context for an agent to invoke it correctly.

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

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

The input schema already covers both parameters with descriptions and examples (ticker or CIK). The description repeats the parameter guidance and adds that the entity is a US public company, but does not materially extend the schema's semantics. With high schema coverage, baseline 3 applies.

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

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

The description clearly states the tool's function: it builds a full cross-source profile of a US public company in one parallel call. It lists specific output components (filings, fundamentals, patents, news, LEI) and distinguishes itself from chaining single-source lookups and from resolve_entity for name-based inputs.

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 directs when to use this tool: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also states exclusion criteria: names are not supported and 'use resolve_entity first if you only have a name.' This provides clear when/when-not guidance relative to siblings.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true. The description adds context that the deletion targets a 'previously stored memory by key,' which clarifies the scope of destruction. It does not over-explain 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?

Three concise sentences pack the action, usage context, and related tools. No redundant or filler content; all sentences earn their place.

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

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

For a one-parameter delete tool with complete schema and annotations, the description fully covers purpose, usage, and pairing, making it complete without needing an output schema.

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 the key parameter described as 'Memory key to delete.' The description merely repeats 'by key' without adding new semantic details, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Delete a previously stored memory by key.' This clearly distinguishes it from sibling tools like remember (store) and recall (retrieve).

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

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

It explicitly states when to use the tool: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also recommends pairing with remember and recall, giving clear context for its role.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds meaningful behavioral detail: it fetches the page, extracts title/description/key links, and emits a standard markdown blob. This goes beyond the annotations by describing the operational workflow.

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

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

The description is efficient: two sentences plus a short list of use cases. It front-loads the core action and result, then provides actionable context. Every sentence earns its place with no redundancy.

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

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

For a tool with two parameters, full schema coverage, and no output schema, the description is complete: it explains the output format ('single text blob'), the process, and the use cases. It does not mention error handling (e.g., invalid URLs), but that is not critical given the annotations and simplicity.

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

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

The input schema covers both parameters with descriptions, so the baseline is 3. The description does not add significant parameter-level detail beyond the schema, but it does reinforce that the URL can be 'any URL' and describes the output format, which indirectly clarifies the purpose of the parameters.

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

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

The description clearly states what the tool does: 'Generate a production-ready llms.txt file for any URL' and walks through the process (fetches, extracts, emits). It is specific and distinct from sibling tools, which focus on checking visibility or scanning presence, not generating llms.txt files.

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 'Useful for' section outlines concrete scenarios: getting a client's site indexed, drafting for your own project, or auditing a competitor. While it doesn't explicitly name alternatives or exclusions, the context is clear enough that an agent can determine when to use this tool over others.

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, covering the safety profile. The description adds value by disclosing exact return fields (id, type, params, created_at, last_fired_at, fire_count) and clarifying the default 'active' filter, which goes 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?

Two concise sentences: the first states the purpose and return fields, the second provides usage guidance. No unnecessary words; content is front-loaded and every sentence earns its place.

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

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

Despite having no output schema, the description explicitly lists the return fields. Complexities are low (one optional parameter, no nested objects). The description covers what the tool does, what it returns, and practical use cases, making it complete for this simple 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 has 100% coverage for the single parameter include_inactive, including its type and default behavior. The description does not add additional meaning about this parameter beyond what the schema already provides, so the baseline score 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 uses a specific verb ('List'), identifies the resource ('subscriptions'), and scopes to 'the caller's active subscriptions'. It distinguishes from sibling tools like subscribe and unsubscribe by noting it helps find an id to cancel, 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 provides clear context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This explicitly states when to use the tool. It does not explicitly mention when not to use it or alternatives, but the context makes the intended usage obvious.

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

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

The annotations provide no behavioral hints (all false), so the description carries the full burden. It discloses key behaviors: 'Rate-limited to 5 per identifier per day,' 'Free; doesn't count against your tool-call quota,' and that the team 'reads digests daily and signal directly affects roadmap.' It also advises not to paste end-user prompts. This goes well beyond what annotations offer, with 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 longer than average but every sentence serves a purpose: purpose, use-cases, exclusions, content guidance, and operational details. It is front-loaded with the core action and then builds context logically. It could be trimmed slightly, but it remains structured and information-dense.

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

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

Given no output schema and all-false annotations, the description covers the essential context: what to report, when to report it, how to frame it, and operational nuances like rate limits and quota. It doesn't explicitly describe the return value, but for a feedback tool that is minor. The overall context is sufficient for correct 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?

The schema already provides 100% coverage with detailed enum descriptions for 'type' and field descriptions for 'context' and 'message'. The description adds value by explaining the message should be 'in terms of Pipeworx tools/packs — don't paste the end-user's prompt,' which is not in the schema. It also gives examples for type values in the usage section, slightly enriching parameter 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 opens with a clear action: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It identifies the resource (Pipeworx team) and enumerates specific feedback types (bug, feature, data_gap, praise), making the tool's purpose distinct from any sibling. The verb+resource structure 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?

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

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context beyond that: it is 'self-aggregating,' derived from 'CF analytics-engine,' confirms 'no PII,' and discloses caching behavior ('Cached 5min-1h depending on window'). These details inform freshness and privacy expectations, exceeding what annotations cover.

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. It opens with a clear purpose, lists outputs and windows, then presents numbered use cases, and ends with important technical details (aggregation, PII, caching). Every sentence adds value, and the format is scannable without excess verbosity.

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

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

For a simple tool with one optional parameter and no output schema, the description is remarkably complete. It explains what is returned, available windows, use cases, data provenance, privacy, and caching. This leaves little ambiguity for an agent to decide when and how to invoke it correctly.

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

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

The input schema already provides 100% coverage for the single parameter 'window,' including an enum and a description of what each value means. The tool description merely mentions 'recent window (24h, 7d, or 30d)' without adding new semantic information. Since schema coverage is high, the baseline is 3, and the description does not elevate it.

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

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

The description opens with a clear, specific statement: 'What other AI agents are calling on Pipeworx right now.' It explicitly names the resource (Pipeworx trending data), the action (returns), and the output components (top tools, top packs, total call volume). This clearly distinguishes it from siblings like discover_tools by focusing on agent-driven popularity signals.

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 three explicit 'Useful for' scenarios, giving clear context on when to use the tool: discovering hot data sources, confirming canonical choices, and aligning use cases. However, it does not mention alternatives or when not to use the tool, so it stops short of full exclusion 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 mark the tool as read-only, idempotent, and non-destructive, reducing the burden. The description adds substantial behavioral context: the semantic similarity threshold (>=0.30 Jaccard), partition placeholder filtering, fill-check lookups against live CLOB depth, and specific response fields. It also flags when a signal should NOT be traded, which is critical operational nuance.

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

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

The description is dense but every sentence earns its place. It opens with a one-sentence overview, then systematically explains invocation modes, internal filters (SEMANTIC ANCHOR, PARTITION FILTER), response shape, and fill-check behavior. Section labels (CAPS) break the text into scannable chunks, and there is no filler or tautology.

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

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

Despite lacking an output schema, the description enumerates the response fields (opportunities[], gap_pp, suggested_trade, reasoning, partition_check fields). It covers edge conditions (placeholder filters, low similarity, fill check failure), explains both event and topic modes, and references related tools. The complexity of this tool is high, and the description fully prepares an agent to invoke it correctly and 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?

Although schema descriptions cover 100% of parameters, the tool description adds significant meaning beyond them: it explains the difference between event and topic modes with concrete slug examples, describes what happens in each mode (walks child markets, checks date-axis ordering, searches related events), and notes cross-event patterns that single-event mode misses. This transforms the schema from a bare list into actionable usage knowledge.

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

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

The description opens with a precise verb+resource statement: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly differentiates three invocation modes (no args, event, topic) and distinguishes this from sibling tools like polymarket_edges and polymarket_fill_risk, which are referenced explicitly when relevant.

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

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

Provides explicit when-to-use guidance: use event mode for specific markets, topic mode for cross-event scans, and no-args for trending scan. It even names an alternative tool for custom sizing (polymarket_fill_risk) and warns against trading when fill check shows the edge is not realizable in the book.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Beyond this, the description reveals caching ('Cached 1h at the KV level'), the response structure with _diagnostics for empty segments, the slippage and Kelly cap details, and the 'Market moved X.Xpp in 24h' warning, all of which enrich behavioral understanding 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 front-loaded with the core purpose and provides a structured breakdown of model families, response segments, knobs, and caching. While it is lengthy and includes implementation details like per-sport α values and Run 8 gate parameters, the dense information is organized and serves the tool's complexity. It could be more concise but earns a 4 for clear structure.

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 compensates by detailing the response top-level keys (by_segment, fed_candidates, _diagnostics), the fields carried by each opportunity, and the diagnostic funnel counters. It also explains why segments may be empty and the reliability caveat for Fed bets, making it complete for an 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?

The input schema covers 100% of parameters with detailed descriptions (e.g., slippage_pp explains Polymarket's zero fees and typical 20-50bp impact). The description only rephrases the knobs at a high level ('drop opportunities where edge isn't realizable') without adding new semantic information. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price,' clearly stating the action, resource, and output. It also distinguishes itself by being 'Built for "what should I bet on today"' and listing three distinct model families, differentiating 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 states it is built for agents to 'discover opportunities without paging hundreds of markets,' giving a clear when-to-use context. It also notes Fed bets are 'excluded from ranking' due to unreliable signals, providing an implicit exclusion. However, it does not explicitly name alternative tools or list scenarios where another tool would be more appropriate.

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

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

With annotations already declaring this as read-only, idempotent, and non-destructive, the description adds valuable behavioral details: the 60-day TTL limit, snapshot gaps due to cache-miss behavior, and that decay is computed from daily closes (not intraday). These disclosures go well beyond the annotations and help the agent set expectations.

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

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

The description is dense but efficiently structured: a clear opening purpose statement, followed by Args, RESPONSE, and LIMITS sections. Every sentence provides distinct information—no fluff or repetition. It is front-loaded with the core question it answers, making it easy to digest.

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 return structure (tracked[], expired[], snapshot_dates[]) and their semantics. It also covers data availability, TTL limits, and computation methodology. For a tool with two optional parameters and no output schema, this is a complete and self-contained description.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description restates defaults ('days (lookback, default 14, max 30)') and adds context for 'window' as a 'snapshot family', but it does not materially extend what the schema already documents. It meets the baseline without adding significant new meaning.

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

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

The description clearly states the tool's function: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It asks a specific question it answers ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools like polymarket_edges by focusing on time-series persistence rather than current edge values.

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

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

The description explains when to use the tool: when you need to understand edge persistence and decay, or to differentiate fresh vs. old edges. It provides clear context about its data source and limitations, but it does not explicitly name alternative tools or state when not to use it, leaving some room for inference.

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, which align with the description's 'check' framing. The description adds substantial behavioral context: it 'walks the ladder,' returns a verdict, and discloses the risk that 'partial basket fills convert an arb into an unhedged directional position'—beyond what annotations convey. No contradiction.

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

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

The description is long but well-organized into SINGLE-MARKET and BASKET sections with capital labels, and every sentence contributes essential information given the tool's complexity. It could be tightened slightly, but the structure aids navigation and the density is justified.

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

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

With no output schema, the description enumerates return fields for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp, theoretical_sum, realizable_sum, thin_legs, forced_directional_risk). It also covers usage constraints, defaults, and risk rationale, making it self-sufficient for an agent to 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?

Although schema coverage is 100%, the description adds mode-dependent semantics: it explains that `market` triggers single-market mode, `event` triggers basket mode, `side` defaults differ by mode, and `size_usd` is interpreted as spend/proceeds in single-market vs settlement notional in basket. This goes far beyond the schema's basic field 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 opens with a specific verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It clearly differentiates single-market and basket modes and explicitly positions itself as a pre-action check for polymarket_arbitrage and polymarket_edges, distinguishing it from those 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 gives explicit when-to-use guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why (theoretical overround not capturable on thin books, partial fills create unhedged positions), providing clear context versus 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?

Despite annotations already indicating readOnlyHint=true and idempotentHint=true, the description adds rich behavioral context: compatibility_warning conditions, temporal_alignment field, skipped_cross_type/subtype counters, and the semantic meaning of matched_pairs=0. It explains what the tool does when bet shapes are non-equivalent, which goes far 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 long but appropriately structured for the tool's complexity. It opens with purpose, then explains modes, response fields, and safety warnings. While some redundancy exists (e.g., 'pre-mapped ≠ tradeable' emphasized at end), every section adds necessary detail. It is front-loaded with the core purpose, and the dense content is justified.

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

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

Given the absence of an output schema, the description fully covers the response format (leg-by-leg prices, spread.pp, compatibility_warning, temporal_alignment), edge cases (skipped_cross_type, matched_pairs=0), and practical caveats. It is complete enough for an agent to understand what the tool returns and when to trust the result.

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

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

Schema coverage is 100% (all three params have descriptions), so baseline is 3. The description adds substantial meaning by explaining the interaction between topic and explicit overrides, the auto-fetch behavior of topic mode, and how to interpret parameter choices. It clarifies that kalshi_event_ticker and polymarket_event_slug override the topic mapping, which is not obvious from schema alone.

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

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

The description clearly states the tool computes 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' which is a specific verb+resource. It distinguishes itself from siblings like polymarket_arbitrage by focusing on cross-venue comparison and explicitly describes two modes (topic and explicit) with examples.

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

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

The description provides thorough usage context: explains the two modes, lists pre-mapped shortcuts, and warns that 'most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.' It does not explicitly name alternative tools, but the context is clear enough to guide when to use this tool versus others.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context beyond annotations: scoping ('Scoped to your identifier...'), the two operational modes (retrieve vs list), and the data provenance (saved via remember). No contradiction with annotations.

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

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

Three sentences, front-loaded with the core action. Every sentence adds value: the first states functionality, the second gives use cases, the third explains scope and related tools. No wasted words.

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

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

Given the simple tool (1 optional param, no output schema) and strong annotations, the description is complete: it covers purpose, usage, scope, and relationships to remember/forget. It also indicates the return types (value or list of keys), which is sufficient given the lack of an output schema.

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 parameter description ('Memory key to retrieve (omit to list all keys)'). The tool description reinforces this and adds semantic richness with examples of what keys represent (target ticker, address, research notes), going slightly beyond the schema baseline.

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

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

The description uses a specific verb ('Retrieve') and resource ('a value previously saved via remember'), and clearly distinguishes from siblings by also mentioning 'list all saved keys'. It also references related tools (remember, forget), making its role unambiguous.

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

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

The description explicitly states when to use the tool: 'look up context the agent stored earlier' with concrete examples (ticker, address, notes). It also gives alternatives: 'Pair with remember to save, forget to delete', providing clear selection guidance.

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

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

The description contradicts the readOnlyHint annotation: it states mark_read:true will 'flag returned events read' and that the 'next call only shows newer ones', which is a state-changing side effect. This is a serious annotation conflict that overrides the otherwise rich behavioral detail.

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 the primary purpose, and every sentence adds useful context. 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?

The description explains the data source (evaluator-written feed), return payload contents, filtering, polling behavior, and alternative endpoint. Since there is no output schema, describing the returned fields helps completeness, though limit/unread_only semantics are only in the schema.

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 meaningful value by giving a concrete type example ('sec_8k'), specifying ISO timestamp format, and clarifying the cross-call consequence of mark_read. It does not repeat limit/unread_only details, but the schema already covers those.

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

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

The description uses a specific verb+resource ('Pull fired events from your subscription feed') and clearly states what is returned (most recent alerts, source, citation_uri, raw payload). It differentiates from siblings like list_subscriptions by focusing on the fired-event feed rather than subscription management.

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

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

The description gives clear usage context: filtering by type and since, using mark_read to affect future calls, and polling suitability. It also mentions an alternative GET endpoint, though it does not explicitly contrast with sibling tools or state when to avoid this tool.

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

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

The description discloses detailed behavior beyond annotations: it fans out to multiple sources, explains fallbacks, flags the PatentsView API sunset, and describes the return structure (changes[], total_changes, citation URIs). Annotations already indicate read-only/idempotent, but the description adds rich operational context.

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

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

The description is dense but well-organized: it opens with query examples, then explains sources, fallbacks, date formats, output, and alternatives. Every sentence contributes critical information, and the structure is logical and scannable.

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

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

Given the complexity (multiple data sources, fallbacks, date handling, output shape), the description is complete. It explains the output because no output schema is present, covers all parameters, and addresses failure/fallback behavior. It leaves no critical gaps for an agent to misinvoke.

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

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

Schema covers all three parameters (100% coverage), but the description adds practical meaning: it gives explicit format examples for `since` (ISO date or relative shorthand) and a recommendation for typical monitoring ('30d' or '1m'). This goes beyond the schema's terse 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 this is a 'change feed for a company in the last N days/weeks/months' with a specific verb and resource, and it distinguishes itself from entity_profile by noting the latter is for static profiles. The phrasing directly addresses the intended use case.

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 query examples, describes fallback behavior (GDELT→GNews, USPTO soft-fail), and explicitly instructs to use entity_profile when a static profile is needed. This gives clear when-to-use and when-not-to-use guidance with a named alternative.

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

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

The description adds useful behavioral context beyond annotations: storage scoped by agent identifier, retention differences for authenticated vs. anonymous sessions, and the key-value format. No contradictions with annotations (readOnly=false matches 'save', idempotentHint=true aligns with idempotent storage).

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 and front-loaded: first the core action, then usage context, then retention scoping and pairing with siblings. Every sentence contributes meaningful guidance without redundancy.

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

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

For a simple write tool, the description covers purpose, when to use, storage semantics, retention behavior, and related tools. No output schema exists, but return value is not essential for this operation. The description fully 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?

Input schema has 100% coverage with detailed examples for both 'key' and 'value'. The description mentions 'key-value pair' but does not add parameter-specific details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool saves data for later reuse, with a specific verb ('Save') and resource ('data'). It explicitly distinguishes from sibling tools by mentioning 'Pair with recall to retrieve later, forget to delete.'

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

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

The description gives explicit when-to-use guidance: 'Use when you discover something worth carrying forward' with concrete examples. It also names the complementary alternatives (recall, forget) and provides retention-policy context to help 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 provide readOnly, openWorld, and idempotent hints, but the description adds substantial behavioral context: cascading through multiple lookup endpoints, returning specific identifier types (e.g., ticker, CIK, RxCUI), providing citation URIs, accepting multiple input formats, and auto-disambiguating. This goes well beyond the annotations and clearly explains what happens during execution.

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 every sentence adds unique value: examples of user queries, explicit supported types, output details, citation URIs, and a note about efficiency. It is well-structured with a clear main clause, supported types breakdown, and a closing benefit statement. No filler or repetition.

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

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

Given that there is no output schema, the description is remarkably complete. It covers input formats for both entity types, output fields, citation URIs, and the internal cascading behavior. It also explains the tool's broader role in the ecosystem (replacing 2-3 manual lookups), which helps an agent decide when to invoke it. The only minor gap is the absence of error behavior, but that is not necessary for this level of completeness.

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

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

The schema already covers both parameters with good descriptions (100% coverage). The description supplements this by offering concrete examples for each type ('AAPL', '0000320193', 'ozempic') and explaining the return mapping (ticker + CIK + company_name for company; RxCUI + ingredient + brand for drug). This adds practical semantics beyond the schema's baseline.

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

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

The description clearly states a specific purpose: resolving user-spoken names to canonical identifiers. It uses concrete verbs and examples ('What's the ticker for...', 'find the CIK for...') and distinguishes itself from sibling tools like compare_entities or entity_profile by focusing on ID lookup. The supported types (company, drug) are explicitly listed, making the tool's scope 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 tells the agent when to use the tool: 'Use FIRST whenever you have a name but need an ID.' This is strong guidance. It also implies that the tool replaces multiple manual lookups, but it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Beyond the annotations (readOnly, idempotent), the description adds valuable behavioral detail: it reveals internal probing via ai_visibility_check, ranking behavior, and the returned ranked list with score, confidence, and signal density. This exceeds the safety profile already covered by 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, each earning its place: the core action, the mechanism, a use case, and the return format. Front-loaded with the verb and resource, with zero 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?

The description covers the purpose, internal mechanism, return values, and typical use case. With no output schema, it compensates by describing the ranked list contents. The sibling tool context and annotations provide sufficient surrounding information.

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

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

Schema coverage is 100% and the description adds no extra parameter meaning beyond what the schema already provides. The schema itself already documents the first-entity-as-subject rule and optional context, so the description does not elevate the baseline.

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

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

The description opens with a specific verb and resource: 'Compare AI visibility across multiple entities side-by-side.' It distinguishes itself from the sibling tool ai_visibility_check by explicitly stating it probes multiple entities and ranks them, making the comparative scope clear.

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

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

Provides clear context with 'Useful for competitive AI-marketing audits' and a concrete example question. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed will list timeouts while the rest still returns. 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 five sentences but each carries unique, necessary information: purpose, use cases, return fields, scope, and failure behavior. It is front-loaded with the core purpose and avoids waste.

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

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

With no output schema, the description compensates by listing the exact return fields (is_latest, license, bundle_kb_min, etc.) and explaining failure handling and latency. It is complete for a multi-source tool.

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

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

Schema coverage is 100%, with both parameters (package, version) fully described. The description adds no parameter details beyond the schema; the version default is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly defines the tool as a composite npm package viability check, fanning out to deps.dev and bundlephobia. It lists specific data points (license, advisories, version history, bundle size, ESM/tree-shake) and distinguishes from non-npm ecosystems via 'deps.dev:version'.

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

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

Explicitly states use cases: "whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me'." It also provides exclusions and alternatives: "NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly."

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

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

While annotations already declare readOnly/idempotent, the description adds crucial details: the BGE-base-en embedding model, 500-char overlapping windows, a 200K char cap with truncation flaging, and the presence of character offsets for verification. These behaviors are not inferable from annotations/schema.

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 five sentences, but each sentence carries a distinct purpose: purpose, input/output, usage guidance, sibling pairing, and technical constraints. It is front-loaded with the core purpose and not padded with filler. Appropriate length for the tool's complexity.

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

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

Given no output schema, the description still explains the return format (top-N passages with character offsets and similarity scores). Combined with the detailed algorithm and cap, the description is fully self-contained for this complexity level. 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 schema already documents all 3 parameters with 100% coverage, so the baseline is 3. The description adds context for 'text' as a previously fetched record and clarifies the output includes offsets/scores, but does not redefine parameter syntax. It gives one extra example for 'query' beyond the schema's, adding some value.

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

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

The description opens with 'Semantic search INSIDE a fetched record,' specifying the action (search), resource (a fetched record), and scope (inside that record). It also distinguishes itself from the sibling ask_pipeworx_grounded by explaining it operates on the already-fetched passages. Clear verb, resource, and boundary.

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

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

Explicitly states 'Use when the record is too big to cram into the prompt — search_within saves context, returns only the passages that matter.' It also advises pairing with ask_pipeworx_grounded, offering a concrete workflow. This meets the when-to-use 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?

Beyond the annotations (which only indicate readOnly=false, openWorld=true, idempotent=true), the description discloses important behaviors: account persistence requirement, always-on feed delivery via recent_alerts/GET endpoint, email/SMS channels with phone verification and a 10/day cap, and that the feed is always active even without additional delivery channels. It also notes the return value, making the tool's behavior predictable.

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

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

The description is front-loaded with the core purpose and return value, then logically expands into account requirements, type examples, and delivery options. It is longer than average but every sentence contributes valuable information, making it appropriately sized for a tool with multiple subscription types and delivery configurations.

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

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

Given the tool's complexity (3 parameters, nested objects, multiple type enums) and the absence of an output schema, the description adequately covers essential aspects: return value (subscription id), account prerequisites, type-specific examples, and delivery behavior. It does not repeat webhook details from the schema but provides enough context for an agent to correctly invoke the tool.

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

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

The input schema already provides 100% coverage with detailed descriptions for each parameter and nested properties. The description adds concrete examples (e.g., 'items:["5.02"] = officer change') and clarifies delivery channel semantics (feed always on, optional email/sms), going slightly beyond the schema by illustrating real usage scenarios.

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 with a specific verb and resource: 'Create a proactive monitoring subscription to a live-data event stream.' It also specifies the return value ('Returns the new subscription id') and distinguishes itself from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

The description provides clear context for use, including the prerequisite that 'Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions)' and details supported types with examples (e.g., sec_8k, polymarket_edge, fred_series). It implies when to use the tool but does not explicitly name alternatives or when-not-to-use conditions beyond the account requirement.

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 value by disclosing the return shape ('category-bucketed example questions', 'exact tool + argument shape') and that results are drawn from the live catalog. No contradiction with annotations.

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

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

The description is somewhat lengthy with a long list of paraphrased user queries up front, but it is front-loaded with purpose and organized into usage instructions. Every sentence contributes useful context, so the verbosity is justified.

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

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

Given the tool's complexity and the rich annotations, the description is complete: it covers when to use, how to call (no-arg vs topic), what output to expect, and how it relates to meta-tools. It even notes the live catalog source and provides category examples, making it self-sufficient even without an output schema.

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

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

Schema description coverage is 100%, and the input schema already documents the optional 'topic' parameter with its allowed categories and omit behavior. The description adds concrete examples ('finance', 'pharma', 'betting') and clarifies that passing a topic 'focuses' the output, but this is only a marginal enhancement over the schema.

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

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

The description clearly identifies the tool as an onboarding entry point that returns category-bucketed example questions with the exact tool and argument shape, using specific verbs like 'Returns' and 'Call'. It distinguishes itself from siblings by explicitly positioning itself as the 'FIRST' tool to use when learning what Pipeworx can do.

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

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

The description gives explicit when-to-use guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you', and explains the two calling modes (no arguments for full spread, or pass a topic). It does not explicitly name alternative tools to use instead, but the context is clear.

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

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

The annotations already indicate non-destructive (destructiveHint=false) and mutating (readOnlyHint=false), but the description adds valuable context beyond that: the row is deactivated not deleted, and historical events remain available. It also states the ownership enforcement rule. This meaningfully informs the agent of behavioral consequences not fully captured by 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 concise sentences, front-loaded with the verb and resource. The second sentence adds essential behavioral details without waste. Every word earns its place, making it highly efficient and readable.

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

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

For a simple one-parameter tool, the description covers the key behavioral aspects: ownership, deactivation, and data retention. It does not describe the return value or error behavior, but no output schema exists and the action is straightforward. The annotations supplement with idempotency and non-destructive hints, so the description is sufficiently complete for the tool's complexity.

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

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

The input schema has 100% coverage with one parameter 'id' and a clear description ('Subscription id (uuid) returned by subscribe'). The tool description merely says 'Cancel a subscription by id' and does not add extra semantic detail beyond the schema. Per the baseline for high schema coverage, a 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 action ('Cancel a subscription by id') and specifies the resource (subscription), distinguishing it from siblings like subscribe and list_subscriptions. It also adds scope ('Ownership is enforced — you can only cancel your own subscriptions') and clarifies the non-destructive nature, making the 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 provides clear context for when to use this tool: when canceling a subscription, with an explicit ownership constraint. It also implies how it relates to recent_alerts by mentioning historical events stay available, but it does not explicitly name alternatives or state when not to use this tool. This is strong context without exclusions, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint:false. The description adds useful context: the return verdict categories, the two-pipeline routing, and the fact that it bypasses multiple sequential calls by combining parsing, entity resolution, data lookup, and comparison. It doesn't contradict the annotations and provides additional behavioral detail.

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 information-rich, but every sentence carries useful meaning. It starts with trigger phrases, then defines the scope, explains the routing logic, and ends with return value details. It is somewhat long but well-structured and front-loaded with the most important usage cues.

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 takes on the burden of explaining return values, which it does: verdict categories, actual value with citation, and reasoning. It also covers edge cases (unsupported verdict), the two modes, and the claim types. The description is 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 description coverage is 100% for both parameters. The 'claim' parameter has a clear description with examples, and 'tolerance_pct' overrides the default tolerance. The main description adds examples but does not significantly elaborate beyond the schema, so a baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'natural-language claim verification against authoritative sources.' It gives specific trigger phrases ('Is it true that…', 'fact check', 'verify the claim that…') and describes the output verdict types. It distinguishes itself from siblings by noting it 'Replaces 4–6 sequential calls' and by explicitly describing the two routing paths (SEC EDGAR for financial claims, grounded pipeline for others).

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 an explicit usage guideline: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the fast path vs. fallback. However, it does not explicitly say when NOT to use this tool or name alternative tools, so it falls short of a 5.

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