Nsi Bg

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 value by explaining the tool's behavior: it probes multiple LLMs, scores visibility, and returns per-model data. It also clarifies pricing (free vs BYO) and does not contradict annotations.

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

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

The description is concise (three sentences) and well-structured: it starts with core purpose, then specific details (default model, key usage), and ends with use cases. No unnecessary information.

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

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

Given the tool has 4 parameters, no output schema, and annotations covering safety, the description provides sufficient completeness. It explains all parameter usage, return structure, and typical use cases. Could mention error handling but not essential.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the default model, that `_apiKey` is for Anthropic and passed directly, and that 'context' helps disambiguate. This extra context justifies a 4.

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

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

The description clearly states the tool's purpose: probing LLMs for knowledge about an entity and scoring visibility per model. It uses specific verbs ('probe', 'score') and resource ('LLMs', 'visibility'). It distinguishes from sibling tools like ask_pipeworx (general Q&A) and scan_competitor_ai_presence by focusing on scored visibility across multiple models.

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') and explains when to provide certain parameters (e.g., `_apiKey` for Anthropic). However, it does not explicitly contrast with sibling tools or specify when not to use this tool.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false) already carry the safety profile. The description adds genuine behavioral context beyond annotations: it is a routing layer that auto-fills arguments, returns stable citation URIs, and is auto-generated documentation. No contradiction with annotations.

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

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

The description is long but every sentence earns its place: preference rule, domain coverage, routing behavior, trigger phrasing, examples, and sibling routing are all packed in. Key guidance is front-loaded ('PREFER OVER WEB SEARCH', 'START HERE'). Slight redundancy in the example list, but nothing wasted.

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 high-complexity routing tool with 31 siblings and no output schema, the description covers the essentials: when to call it, what it does, what it returns (structured answer with citation URIs), and which alternatives to prefer. The only minor gap is lack of detail on failure/uncertainty behavior (e.g., what happens if no tool matches), but this is a modest omission.

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 thorough alias documentation (question, query, q, prompt, text, input). The description adds semantic value on top by giving trigger phrases and six concrete example questions that teach what a well-formed input looks like, going beyond the schema's bare type declaration.

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

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

States a specific verb and resource: it routes natural-language questions to the right one of 5,908 tools across 1,540 sources and returns structured answers with pipeworx:// citation URIs. It clearly distinguishes itself from siblings by name (deep_research, bet_research, ask_pipeworx_grounded), so an agent can tell it apart without opening other schemas.

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?

Extremely explicit: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', a trigger-phrase list ('what is', 'look up', 'get the latest', etc.), and concrete examples. It even names exclusions: use ask_pipeworx_grounded for dataset/entity-grounding, deep_research for open-ended multi-step research, bet_research for in-licensed betting content.

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, open-world), the description adds meaningful behavioral context: candidate routing improvements are enabled live during tests, no candidate is currently active, and the tool currently matches ask_pipeworx exactly. It also explicitly says it is a full working router, not a fallback stub, which prevents a likely misunderstanding. This is genuinely transparent about what the agent should expect.

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 and front-loaded with the core identity: 'Beta version of ask_pipeworx'. It then explains current behavior, usage, and the no-fallback guarantee. The level of detail, including the retirement date, is arguably more than necessary, but each sentence contributes useful context and the structure is easy to follow.

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 annotations and the fully documented schema, the description is mostly complete for invocation. It tells the agent this is a working router, how to use it, and that the response shape matches ask_pipeworx. The main gap is that the response shape is only referenced through a sibling tool rather than described directly, which is a minor issue because ask_pipeworx appears in the sibling list.

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 description coverage is 100%, and all parameters are aliases for the required 'question' parameter, so the schema already documents the input semantics fully. The description only repeats that the arguments are the same as ask_pipeworx, adding no new parameter-level meaning. 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 clearly identifies this as the beta version of ask_pipeworx, a universal router with the same 5,908 tools, arguments, and response shape. It explicitly differentiates itself from the stable ask_pipeworx by the candidate routing improvements and the experimental edge. 'Falls back to nothing — this IS a full working router' reinforces the tool's actual purpose without ambiguity.

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

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

The description gives a direct usage instruction: use it exactly like ask_pipeworx when you want the newest routing. It also warns that results are compared against the stable router to decide merges, which clarifies its role as an experimental variant. It does not explicitly state when NOT to use it or name a stable alternative beyond 'ask_pipeworx', but the beta/stable contrast makes the intended selection fairly 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavior beyond those: the explicit refusal protocol with enumerated refusal_reason values, the verbatim-evidence extraction guarantee, the success return shape, and the extra LLM call cost. No contradiction with annotations — the read-only fetch/extract behavior is consistent with readOnlyHint=true.

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

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

Front-loaded with the core purpose, then flows logically through mechanism, return shapes, refusal behavior, use-when conditions, and cost comparison. Dense and information-rich; every sentence earns its place, though the description is on the longer side and could be slightly tightened without losing meaning.

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

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

For a complex routing tool with no output schema, the description is remarkably complete: it documents the full success return shape, all five refusal_reason enum values, the use conditions, and the cost tradeoff against ask_pipeworx. An agent has everything needed to invoke it correctly and interpret both success and failure responses.

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 schema already documents the 'question' parameter and its aliases. The description adds general context — that the question is routed across tools and fills arguments — but no parameter-specific syntax, format, or length guidance beyond what the schema provides. Baseline 3 applies 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 states a specific purpose — 'Hallucination-resistant answer mode for high-stakes reads' — with a clear verb (answer/extract) and resource (tool results from 5,908 tools across 1540 sources). It distinguishes itself from the sibling ask_pipeworx by its grounded, evidence-extraction behavior and refusal protocol, so an agent can tell them apart without opening the schema.

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 specifies when to use this tool: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with concrete domains (financial verdicts, legal claims, medical lookups, public statements). It also names the alternative and the condition for choosing it: 'prefer ask_pipeworx for casual lookups' with the cost tradeoff stated. Nothing is left to 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?

The description adds extensive behavioral details beyond annotations: resolver contract (match confidence, alternatives), parent_event extractor, news fields with fallbacks, safety mechanisms (low-confidence short-circuiting, closed markets), wide-spread handling, and resolution-rule risk parsing. No contradictions with annotations (readOnly, openWorld, idempotent, non-destructive).

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

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

The description is long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). Every sentence provides useful information. Minor improvement: could reduce some redundancy (e.g., repeated mention of low_confidence_match).

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

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

Given the tool's complexity (3 params, no output schema), the description covers resolution logic, edge cases, fallbacks, and safety mechanisms thoroughly. It explains response shapes, making up for missing 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%, so baseline is 3. The description adds value by explaining the flexible input format for 'market', default depth behavior, and when to set 'include_raw' to true (detailed responses vs. summaries).

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

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

The description clearly states the tool's purpose: research a Polymarket bet by pulling Pipeworx data. It specifies inputs (slug, URL, question text) and outputs (evidence packet, comparison). It distinguishes itself from siblings by offering a combined research call for betting decisions.

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 use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. It provides good guidance but does not explicitly mention when to use alternative tools among the large sibling set.

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 nature. The description adds significant behavioral context: data sources (SEC EDGAR/XBRL, FAERS), handling of off-calendar fiscal years, sorting by primary metric, and return of citation URIs. No contradictions with annotations.

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

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

The description is front-loaded with trigger phrases and each sentence provides distinct value. It is slightly verbose but efficient given the detail needed. Could be trimmed slightly without losing meaning.

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

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

Given moderate complexity (2 params, no output schema), the description fully covers what data is returned, sorting, and citation format. It compensates for lack of output schema by explaining return structure clearly.

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

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

Schema coverage is 100% with both parameters described. The description adds meaning beyond schema by explaining how values are interpreted (tickers/CIKs vs drug names), constraints (min/max items), and the data context (latest 10-K, FAERS counts).

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 side-by-side comparison of 2–5 entities (companies or drugs) with specific metrics for each type. It distinguishes from sibling tools by preferring over sequential single-pack lookups and quantifies efficiency (replaces 8–15 sequential lookups).

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

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

The description explicitly advises 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides trigger examples. It lacks explicit when-not-to-use scenarios but gives strong contextual 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 readOnly/openWorld/idempotent/non-destructive, so the bar is raised, and the description clears it easily. It adds account/auth prerequisites, latency expectations (15-60s, up to ~90s), output-packet structure (verbatim evidence, confidence, source, fetched_at, gaps[], contradictions[]), guaranteed-resolvable citations, the no-invention guarantee, and semantic excerpting behavior — none of which appears in annotations.

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

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

The description is long but every section earns its place: the critical account gate and fallback tool are front-loaded, followed by scope, mechanism, output format, and timing. It loses one point for mild redundancy (the stable-citation claim is restated as 'enforceable... always fetchable') and a slightly rambling middle section.

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

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

With no output schema, the description must explain return values, and it does thoroughly: the findings packet fields, gaps[] semantics for unanswered facets, contradictions[] for standard/thorough, resolvable pipeworx:// citations, and timing. For a complex parallel-routing tool, nothing an agent needs to decide on or interpret the call is missing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds real value on top: 'thorough' requires a paid plan, the question parameter can be broad/multi-part by design, and depth choices carry latency implications. This goes beyond what the enum descriptions in the schema provide.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1540 STRUCTURED data sources... in ONE call', with a concrete mechanism (decomposes into facets, routes to 5,908 tools in parallel). It also differentiates from siblings explicitly: 'this is NOT open-web search' and 'For a single lookup use ask_pipeworx instead'. Example questions make the intended use 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?

Provides explicit when-to-use guidance ('Best for broad/multi-part questions over structured data' with two concrete examples), explicit when-not-to-use ('For a single lookup use ask_pipeworx instead'), and an account-gating condition ('If you are not signed in, use ask_pipeworx instead — it works on every tier'). It even disambiguates depth tiers by plan cost.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds valuable context: returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed', which describes behavior beyond the annotations.

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

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

The description is a single paragraph of 4 sentences, front-loaded with the core purpose. It contains useful information without fluff, though it could be split into shorter sentences for easier scanning. Still, every sentence adds value.

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

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

Given 6 parameters (all aliases) and no output schema, the description adequately explains the return format (top-N with schemas and examples) and usage timing. It does not cover edge cases or failure modes, but for a tool discovery tool, this level of detail is sufficient.

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 each parameter described. The description adds value by clarifying that 'query' accepts aliases (task, q, description, search) and that it takes a natural language description, which is not perfectly captured in individual schema descriptions. However, the schema already handles basic semantics, so not a 5.

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

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

The description explicitly states 'Find tools by describing the data or task' and lists many specific domains (SEC filings, financials, etc.), clearly distinguishing 'discover_tools' from sibling tools like 'deep_research' or 'search_within' which are for different purposes.

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

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

The description advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer)', providing explicit when-to-use guidance. It also lists use cases (browse, search, look up) and does not leave usage ambiguous.

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, but the description goes well beyond them by detailing the fan-out across SEC EDGAR, XBRL, USPTO, USAspending, FDA, DOL, news, and GLEIF; the meaning of sources_used/sources_failed; the 'empty section is a real no data' behavior; and the resolved:false path for private companies. This is rich, non-redundant behavioral context.

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

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

The description is long, but it packs dense, non-redundant behavioral information into a structured flow: triggers, source fan-out, return fields, failure semantics, and input handling. The user-phrase examples at the start are a bit repetitive, but overall every segment earns its place given there is no output schema to convey return details.

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 carries the full burden of explaining return values, and it does so thoroughly: cik, company_name, resolution details, recent_filings with URIs, fundamentals, sources_used/sources_failed, and the private-company failure path. It covers input variants, source list, and edge-case behavior, leaving no critical gap for an agent deciding whether and how to invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the accepted value shapes (ticker, CIK, company name) already documented in the schema and adds some illustrative examples and zero-padded CIK format, but it does not materially expand parameter semantics beyond what the schema already provides.

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

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

The description states a clear, specific purpose: 'full cross-source profile of a US public company in ONE parallel call.' It also enumerates example user phrasings ('Tell me about X', 'company profile for Microsoft') and explicitly distinguishes itself from chaining single-pack SEC/XBRL/news lookups, making it easy for an agent to identify when this tool applies.

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 guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also clarifies accepted input forms (ticker, CIK, company name) and behavior for private companies. It could have named specific sibling alternatives like compare_entities or resolve_entity, but the primary usage context is clear.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. Description adds 'clear sensitive data' context but does not disclose further behavioral traits (e.g., idempotency, read-only). No contradiction with annotations.

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

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

Two sentences, no redundant words. First sentence states action, second provides usage guidance. Efficient and front-loaded.

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 1-parameter tool with annotations covering destructiveness, the description covers purpose, usage, and pairing with siblings. No missing context.

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

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

Schema coverage is 100% (description for 'key' matches schema). Description adds no additional meaning beyond the schema's 'Memory key to delete'.

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?

Explicitly states 'Delete a previously stored memory by key' - a specific verb and resource. Distinguishes from siblings 'remember' and 'recall' by naming them in the description.

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: 'when context is stale, the task is done, or you want to clear sensitive data'. Explicitly names alternatives 'remember and recall' for pairing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it fetches the page and extracts title/description/key links, but does not go beyond basic process. No contradictions with annotations.

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

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

The description is three sentences plus a bullet list, front-loaded with the main purpose and process, then use cases. Every sentence adds value without repetition or 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?

Given the simplicity of the tool (generates a text file) and no output schema needed, the description covers input, process, and output format. Minor omission: no mention of error handling or unsupported URL types, but still adequate.

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

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

Schema coverage is 100% with both parameters documented. The description does not add additional meaning beyond what the schema provides (e.g., url description and max_links default/max). 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 generates an llms.txt file for any URL, with specific verb 'Generate' and resource 'llms.txt file'. It distinguishes from siblings like scan_competitor_ai_presence by explicitly mentioning use cases such as drafting for your own project or auditing competitors.

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 enumerates three clear use cases: indexing client sites, drafting for own projects, and auditing competitors. It implies when to use but lacks explicit when-not-to-use or alternative tool references, though the sibling list suggests some overlap.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral detail about the output format (JSON-stat 2.0 with dimensions, categories, value array) and the source of ids, enhancing transparency beyond annotations.

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

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

Two sentences plus example ids, with no extraneous information. Purpose is front-loaded, and every part is essential.

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

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

Given there is no output schema, the description adequately explains the return format. It also covers how to obtain valid ids. For a simple read tool with comprehensive annotations, this is fully complete.

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

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

Schema coverage is 100% and both parameters are described. The description adds real-world context for the id parameter (example datasets) and notes the default language, providing useful meaning beyond the schema alone.

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

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

The description clearly states the tool fetches a single NSI Bulgaria dataset by numeric id and returns a JSON-stat 2.0 object. It provides specific examples (ids 107 and 242) with context, distinguishing it from sibling tools like list_datasets.

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 implicitly tells when to use (when you have a numeric id from list_datasets) but does not explicitly state when not to use or provide alternative tools. However, the context is clear enough for an AI agent.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by stating the output format (parsed CSV rows) and the content (column codes plus Bulgarian and English names), giving the agent a clear picture of 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 two sentences, concise and front-loaded, with no extraneous words. Every sentence adds value.

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

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

Despite lacking an output schema, the description explains the return format and content sufficiently. The schema fully covers parameters, and the context signals (read-only, idempotent) are handled. Complete for a metadata retrieval tool.

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

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

Schema coverage is 100% with both parameters well-described. The description does not add additional semantic detail beyond what the schema provides, 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's purpose: fetching field/dimension metadata (column codes and names) for an NSI dataset as parsed CSV rows. It distinguishes itself from get_dataset by noting it helps interpret dimension codes.

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 by noting the tool is useful for interpreting dimension codes from a get_dataset response, but it does not explicitly state when not to use it or list alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns dataset id and name, and that filter is case-insensitive. This adds some context but does not significantly extend beyond the annotations.

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

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

The description is concise at 2-3 sentences, front-loaded with the main purpose, and uses a clear structure without unnecessary details.

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?

Although there is no output schema, the description specifies that the tool returns dataset id and name, and references the follow-up tool. It is complete for a simple listing tool, though pagination or size limits are not mentioned (not critical here).

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

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

Schema coverage is 100%, but the description adds value by explaining the 'filter' parameter as a case-insensitive substring match and providing examples. It also clarifies the default for 'lang'. This goes beyond the schema alone.

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

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

The description clearly states the tool lists NSI Bulgaria open-data datasets with numeric id and English/Bulgarian name, and distinguishes it from the sibling 'get_dataset' by noting that the id can be passed there for actual figures.

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

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

The description explains when to use the tool (to list datasets) and provides guidance on using the optional 'filter' parameter with examples. It does not explicitly state when not to use it or list alternatives, 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context about default behavior (active only) and returned fields, providing value beyond annotations without contradiction.

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

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

Two sentences, front-loaded with purpose and output, followed by usage guidance. Every sentence is informative 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?

With no output schema, the description compensates by listing return fields. The tool is simple with one optional parameter, and the description covers purpose, output, and usage thoroughly.

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 description for the parameter is adequate. The tool description does not add additional parameter semantics beyond what's in the schema, warranting baseline 3.

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

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

The description clearly states 'List the caller's active subscriptions' – a specific verb and resource. It lists returned fields and distinguishes from sibling tools like subscribe/unsubscribe.

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

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

Includes explicit guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This tells when to use it, but doesn't explicitly state when not to use it.

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

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

Beyond the annotations (which are all false), the description discloses important behaviors: rate limiting ('Rate-limited to 5 per identifier per day'), quota exemption ('Free; doesn't count against your tool-call quota'), and the return of a claim_token for later lookup ('Filing without an account returns a `claim_token`'). It also explains how the token is used to retrieve resolution status.

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

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

The description is long but dense with necessary guidance; every sentence covers a distinct aspect (purpose, scope, token flow, rate limits, quota). It is front-loaded with the core purpose, though the length slightly exceeds ideal conciseness for a single paragraph.

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

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

Despite no output schema and zero required parameters, the description fully covers what an agent needs: when to use, what to include, exclusions, token handling, rate limits, and team impact. It even explains the return value behavior (claim_token) and its subsequent lookup, making the tool complete in its context.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds meaning by explaining the claim_token usage pattern ('pass it back later as pipework_feedback({claim_token:"pwfb_…"})') and enriching the message parameter ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt'), which goes beyond the schema's generic 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 clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb and resource, and it distinguishes itself from sibling tools by being the feedback channel for Pipeworx-specific tools.

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

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

The description provides explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives exclusions: 'ONLY for tools served by this Pipeworx connection' and tells users to file with other servers otherwise, plus clarifies not to paste the end-user's prompt.

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 no destructiveness. Description adds valuable context: data source (CF analytics-engine), privacy (no PII), caching (5min-1h), and output structure (pack, tool, count). No contradictions.

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

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

Two paragraphs with clear structure: first sentence states purpose, then bullet points list use cases. Every sentence is relevant, no waste, key info front-loaded.

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 1 optional param and no output schema, the description covers return values, aggregation method, privacy, and caching. Fully adequate for an AI agent to understand and use correctly.

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

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

Schema has 100% coverage with description of window parameter and its default. Description adds nuance: shorter windows surface hot trends, longer windows show steady-state demand, enhancing the meaning beyond schema.

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

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

The description clearly states it returns top tools, top packs, and total call volume over a window, specifying the verb 'Returns' and the resource. It distinguishes from siblings like 'discover_tools' by focusing on current usage data.

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

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

Explicitly lists three use cases (discovering hot data, confirming canonical choice, aligning use case). Does not provide exclusions or alternatives, but the use cases are clear and context-rich.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds extensive behavioral details: scanning algorithm (monotonicity checks, partition checks), semantic anchor with Jaccard similarity, partition filter for placeholders, fill check against CLOB depth, and response structure. No contradictions with annotations.

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

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

The description is dense but well-structured, front-loading the main purpose and mode selection. Some details like threshold values (3pp, 0.30 Jaccard) could be streamlined, but every sentence adds value. It is appropriately sized 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?

Despite no output schema, the description fully documents the response structure: opportunities array with fields (gap_pp, suggested_trade, reasoning), partition_check object in event mode, and fill check results (theoretical_edge_pp_at_book, realizable_edge_pp, thin_legs). It also covers edge cases (skipped_low_similarity, placeholders_filtered) and limitations (do not trade if realizable_edge_pp ≤ 0). Completely covers what an agent needs to know to use 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?

Schema provides 100% coverage with descriptions for both event and topic parameters. The description adds extra meaning: event is recommended for specific markets with accepted formats (slugs or URLs), topic is for cross-event scanning with seed questions. It explains the behavior triggered by each parameter, going beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes: no-args trending scan, event mode for specific events, and topic mode for cross-event scanning. The verb 'find' and resource 'arbitrage opportunities' are specific, and the differentiation from siblings like polymarket_fill_risk is implied.

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

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

Explicit guidance is provided: 'Call with NO args for a trending_scan... pass event for... or topic for...'. It recommends event mode for a specific market and explains cross-event mode catches patterns single-event misses. It also warns when not to trade (realizable_edge_pp ≤ 0) and suggests polymarket_fill_risk for custom sizing.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds extensive behavioral context: caching every hour, tradeable-edge knobs, diagnostic output, and detailed model behaviors. It enriches beyond annotations without contradiction.

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

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

The description is dense and detailed, which is justified given the tool's complexity. It is well-structured with numbered segments and clear headers, but could be slightly more concise without losing key information. Every sentence earns its place, but overall length may challenge quick parsing.

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

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

Given no output schema, the description thoroughly covers response structure (by_segment, fed_candidates, diagnostics), caching behavior, and model details. It provides complete context for agents to understand inputs and outputs 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 descriptions for all 9 parameters. The description adds significant value for several parameters (e.g., slippage_pp with context on Polymarket fees, min_partition_leg_kelly explaining partition arbs). The extra explanations help agents understand parameter impact beyond the schema.

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

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

The description clearly identifies the tool's purpose: scanning Polymarket markets and returning opportunities where Pipeworx data disagrees with market price. It specifies the target use case ('what should I bet on today') and distinguishes from sibling tools by focusing on edge identification rather than other aspects.

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

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

The description implies usage for daily betting decisions and explains the model families. It lacks explicit guidance on when not to use this tool versus alternatives like polymarket_arbitrage or bet_research, but the context of sibling tools provides some differentiation. The description gives clear usage context but could be more explicit about exclusions.

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

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

Annotations indicate read-only, idempotent, non-destructive. The description adds rich behavioral details: response structure (tracked, expired, snapshot_dates), data sources (daily closes), limits (60-day TTL), and interpretation notes (edge_pp_net signs). 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 well-organized, starting with purpose, then response fields, then limits. While slightly verbose, all sentences add value. Could be tightened, but still effective.

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

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

Given the tool has only 2 optional parameters and no output schema, the description fully explains the output structure and limitations, making it self-contained 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 already provides 100% coverage for both parameters with descriptions. The description adds minor context (defaults, max for days) but does not significantly expand beyond schema.

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

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

The description clearly specifies that the tool provides 'edge persistence and decay telemetry' and answers a precise question about edge duration and shrinkage. It distinguishes itself from the sibling 'polymarket_edges' by focusing on time-series analysis.

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

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

The description gives a concrete use case (differentiating fresh vs. old edges) and implicitly guides when to use this tool. However, it does not explicitly state when not to use it or mention alternatives among siblings.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds that it requires one of market or event, details return fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and warns about forced directional risk. No contradictions.

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

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

Well-structured with clear sections (SINGLE-MARKET, BASKET) and bullet-like lists, but slightly verbose. Could be more concise without losing key details.

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

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

Despite no output schema, the description lists all important return fields and explains the risk of partial basket fills. For a complex tool with 4 parameters and high-stakes usage, it is contextually complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: REQUIRES condition (market xor event), explains side parameter in both modes, and interprets size_usd for buys vs sells and basket mode, exceeding schema descriptions.

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

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

The description clearly states it performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes, using specific verbs and resources.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains the consequences of not using it (theoretical overround not capturable, partial fills convert arb to directional).

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

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

Annotations already declare read-only, non-destructive behavior, and the description adds substantial behavioral detail beyond that: unverified matching by keyword overlap, gross spreads that ignore Kalshi fees, temporal mismatch semantics where null does not mean aligned, and explicit handling of unclassified legs. It also discloses that compatibility codes can be non-empty even when pairs are returned.

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 and dense, but it is well-structured and front-loaded with the core purpose, then modes, response shape, safety fields, and limitations. Some redundancy and heavy enumeration of codes make it less concise than ideal, but the organization helps an agent navigate the detail.

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

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

There is no output schema, so the description carries the full burden of explaining return values and edge cases. It covers spread semantics, per-pair flags, skipped unclassified legs, temporal alignment semantics, fee disclosure, and the meaning of compatibility codes. This is sufficient for an agent to interpret the tool's output 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 schema already documents all three parameters with 100% coverage, so the baseline is 3. The description adds meaningful semantics by explaining that explicit ticker/slug parameters override the topic-mapped side, that both modes run the identical token-overlap matcher, and how the topic shortcuts map to preconfigured events. This goes beyond the schema's 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?

States a specific verb and resource: it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. The two modes (topic shortcuts vs explicit ticker/slug) are clearly described, and the scope is distinct from sibling tools like polymarket_arbitrage.

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

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

Clearly explains the two modes and how to invoke them, and provides context-sensitive guidance such as 'pre-mapped ≠ tradeable' and that most topics return compatibility warnings. It does not explicitly name alternative tools or state when not to use the tool at all, but the context is strong enough for an agent to decide.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; description adds scoping to identifier and behavior of omitting key, providing useful context beyond annotations.

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

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

Three sentences, front-loaded with verb and resource, no redundant words, every sentence adds value.

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

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

Simple tool with one optional param and strong annotations; missing explicit mention of return format but otherwise complete for its complexity.

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

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

Schema coverage is 100% with parameter description; description adds meaning by explaining key's purpose and listing behavior, exceeding the baseline of 3.

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

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

Description clearly states verb 'retrieve' or 'list all', specifies resource 'value previously saved via remember' and differentiates from siblings like 'remember' and 'forget'.

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

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

Includes explicit use case ('look up context... without re-deriving') and pairing with remember/forget, but lacks explicit when-not-to-use guidance.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds: it returns most recent alerts, explains the effect of mark_read (flags returned events read so next call shows newer ones), mentions unread_only option, and confirms polling works. 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?

Four sentences, front-loaded with core purpose and immediate details. Every sentence adds value: first states purpose, second lists return fields, third explains filters and mark_read, fourth mentions polling and alternative endpoint.

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 5 parameters and no output schema, the description fully explains return values and behaviors (mark_read, unread_only, polling). It covers expected input format and provides an alternative access method. No gaps.

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

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

Schema coverage is 100%, but description adds meaning: type example 'sec_8k', since as ISO timestamp, mark_read explains flagging behavior, limit range (1-200, default 50), unread_only returned events read_at null. All parameters are enriched.

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

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

The description clearly states 'Pull fired events from your subscription feed' and specifies the returned content (source, citation_uri, raw payload). It distinguishes from the numerous sibling tools which have distinct purposes.

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

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

The description explains when to use filters (type, since) and the mark_read/unread_only options. It also mentions that polling works fine and points to an alternative feed for scripts/dashboards. Lacks explicit when-not-to-use guidance, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context: fans out to SEC, GDELT/GNews fallback, USPTO soft-fail, and structured return format. No contradictions.

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

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

The description is a single paragraph but front-loads the purpose with example queries. Every sentence is informative. Slightly more structured formatting could improve scannability.

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

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

Given the tool's complexity (multiple data sources, fallback logic), the description covers return structure (grouped changes, count, URIs), limitations (USPTO soft-fail), and parameter details comprehensively. No output schema exists, but the description sufficiently explains return format.

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%. The description adds meaning beyond schema: explains 'since' formats (ISO date or relative shorthand) with examples, and 'value' as ticker or CIK. Provides practical guidance.

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

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

The description clearly states it provides a change feed for companies (SEC filings, news, patents) and distinguishes it from the sibling tool entity_profile for static profiles. It uses specific verbs and resources.

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

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

The description explicitly says when to use (for 'what's new' queries) and when to use entity_profile instead. However, it does not explicitly list situations where this tool should not be used.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds valuable behavioral context: key-value scoped by identifier, persistent vs. 24-hour retention. 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?

Description is front-loaded with purpose, then usage guidelines, then storage details. Each sentence adds value, though it could be slightly more compact without losing information.

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

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

Given no output schema, description sufficiently covers behavior (write operation) and storage semantics. Explains when to use and how data persists. Complete enough for an agent to use correctly.

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

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

Schema coverage is 100% with clear descriptions for key and value parameters. Description provides example naming conventions but does not add significant meaning beyond schema.

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

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

Description clearly states 'Save data the agent will need to reuse later' with specific examples (ticker, address, preference). Distinguishes from sibling tools 'recall' and 'forget' by mentioning them as paired operations.

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

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

Explicit guidance on when to use: 'when you discover something worth carrying forward' and mentions pairing with recall and forget. Also provides context on persistence differences between authenticated and anonymous sessions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description goes beyond annotations by disclosing cascading internal lookups, graceful degradation ('if GLEIF or OpenFIGI is unavailable, the EDGAR identifiers still return'), ambiguous-match behavior ('returns figi_candidates to pick from'), and explicit 'unresolved' output handling. This provides rich behavioral context fully consistent with the annotations.

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

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

The description is long but front-loaded with the core purpose in the first sentence, followed by examples, supported types, and critical behaviors. Every sentence earns its place—no fluff or redundancy. The structure uses examples and parentheses to pack information efficiently, keeping it readable despite 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?

For a tool with two entity types, multiple data sources, cascading lookups, and no output schema, the description is remarkably complete. It covers input requirements, output composition (identifiers, sources, unresolved list, figi_candidates), edge cases (non-US issuers, non-equity instruments), and failure modes (source unavailability). An agent has everything needed to call and interpret results correctly.

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

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

Schema coverage is 100% and both parameters have descriptions, but the tool description adds significant value: it elaborates on the 'value' parameter with precise instructions for bond issuers ('Pass the ENTITY NAME ONLY… never the full noun phrase'), explains what each type returns (CIK, ticker, LEI, FIGI for company; RxCUI for drug), and clarifies input acceptance (ticker, CIK, ISIN, or name for company). This goes well 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 states a specific verb ('resolve'), a resource ('user-spoken NAME to canonical/official identifiers'), and provides concrete trigger phrases ('What's the ticker for…'). It distinguishes itself as the entry point for name-to-ID resolution, positioning against siblings like entity_profile and compare_entities by saying 'Use FIRST whenever you have a name but need an ID.'

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

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

The description is explicit about when to use the tool: 'Use FIRST whenever you have a name but need an ID.' It also gives positive examples (ticker, CIK, LEI queries) and clarifies ambiguous cases (bond issuer names must be exact, not full noun phrases). It mentions that it replaces 2-3 manual lookups, reinforcing when it should be chosen over 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?

No annotation contradiction; description adds behavioral details: probes each entity with ai_visibility_check, returns ranked list with score/confidence/signal density, beyond the annotations which already mark it as read-only and idempotent.

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

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

Two sentences, no wasted words, front-loaded with purpose and output 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?

No output schema, but description fully explains return format (ranked list with score, confidence, signal density per entity), sufficient for this aggregated probe tool.

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

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

Schema coverage is 100%, but description adds value by clarifying that the first entity is treated as 'subject' and others as competitors, which is not in the schema descriptions.

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

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

Description clearly states verb 'compare' and resource 'AI visibility across multiple entities', differentiating from sibling tools like ai_visibility_check (single probe) and compare_entities (generic).

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 use case ('competitive AI-marketing audits') with example, but does not mention when not to use it or direct to alternatives for single entity probes.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about graceful degradation: 'Partial failures degrade gracefully — bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out, the rest still returns.' This goes beyond annotations.

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

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

The description is detailed and front-loaded with the core purpose. Each sentence adds value, covering purpose, usage, behavior, output structure, and edge cases. Slightly long but justified by thoroughness; 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?

Without an output schema, the description fully details the return structure: summary block fields, per-advisory detail, links, and alternative versions. It also addresses edge cases (timeout, partial failures). Complete for a 2-parameter tool.

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

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

Schema coverage is 100% with both parameters described. The description does not add extra semantic detail beyond what the schema provides, such as the default version behavior which is already in the schema. 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 it's a composite check for npm packages covering license, advisories, version history, and bundle size. It uses a specific verb 'scan' and resource 'dependency', and is distinct from sibling tools which focus on other domains (e.g., AI visibility, betting markets).

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also specifies ecosystem scope 'NPM ecosystem only in v1' and directs to deps.dev directly for other ecosystems. This provides clear when-to-use and when-not-to-use guidance.

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

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

Beyond annotations (readOnlyHint, etc.), description reveals technical details: BGE-base-en embeddings, cosine similarity, 500-char windows, 200K char cap with truncation and flagging, and that passages include offsets for verification.

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?

Concise, front-loaded with key action, uses bullet-point-like structure without symbols, every sentence adds necessary information without redundancy.

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

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

Covers purpose, usage, technical details, limitations, and return format (passages with offsets and scores). No output schema required given this clarity.

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 100%, but description adds value: provides example queries for the query parameter, clarifies the text size limit, and explains the purpose of the limit parameter.

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

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

Description clearly states 'Semantic search INSIDE a fetched record' with specific verb and resource, and distinguishes by noting it pairs with ask_pipeworx_grounded, avoiding confusion with 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?

Explicitly states when to use: 'when the record is too big to cram into the prompt' and how it saves context. Pairs with ask_pipeworx_grounded for grounding. Lacks explicit 'when not to use' but context is clear.

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

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

The description goes beyond annotations by detailing subscription types with examples, delivery channel constraints (e.g., webhook auto-disabled after 10 failures, SMS daily cap), and that the feed is always on. No contradiction with annotations.

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

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

The description is well-structured, starting with the main purpose, then requirements, supported types with examples, and delivery channels. Every sentence adds value, and it's concise 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?

The description covers all subscription types, delivery channels, return value (subscription ID), and how to retrieve alerts. It also addresses prerequisites and constraints, making it complete for an agent to use 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?

The input schema descriptions already cover parameter meanings with examples (100% coverage). The description adds extra behavioral context like the daily SMS cap and webhook signing details, but the schema already provides thorough documentation.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription ID. It distinguishes from siblings 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 context on when to use the tool (for persistent monitoring) and specifies prerequisites (requires Pipeworx OAuth account). It also details constraints for delivery channels (phone verification, 10 SMS cap). While it doesn't explicitly contrast with sibling tools, the usage context is clear.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detailed behavioral context: it explains the return format (category-bucketed example questions with exact tool+argument shapes), that it draws from a live catalog, and how to optionally filter by topic. 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 somewhat long (multiple sentences) but well-structured: it starts with common phrasings, then explains the output format, then usage and where to call it first. It is front-loaded with key information. Could be slightly trimmed, but overall efficient.

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

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

The tool has zero required parameters and no output schema. The description fully explains what is returned (category-bucketed example questions with tool+argument shapes) and the source (live catalog). It also covers the optional topic parameter and gives usage context. Complete for the tool's 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?

Schema coverage is 100% with one parameter (topic) fully described. The description adds significant meaning: it explains that omitting topic returns a full spread, and passing a topic focuses the results, listing possible values like 'finance', 'pharma', etc. This goes beyond the schema's minimal description.

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

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

The description clearly states the tool's purpose: an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It uses specific verbs like 'suggest' and 'returns', and distinguishes from siblings like discover_tools and ask_pipeworx by focusing on onboarding and 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 explicitly advises to use this tool first when the agent does not know what Pipeworx can do, and lists specific use cases like 'getting started' and 'what data do you have?'. It does not explicitly state when not to use it, 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?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description explains the key behavioral detail: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts,' adding transparency that annotations alone do not provide.

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

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

The description consists of two concise sentences with no excessive wording. It front-loads the core action ('Cancel a subscription by id') and immediately follows with critical context, making it efficient and well-structured.

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 single-parameter tool with no output schema and good annotations, the description is fully complete. It covers the action, constraint (ownership), and behavioral nuance (deactivation vs. deletion) without requiring additional information.

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

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

Schema description coverage is 100% and the parameter 'id' is adequately described as 'Subscription id (uuid) returned by subscribe.' The description adds no additional semantic info beyond the schema, so a 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 'Cancel a subscription by id' with a specific verb and resource, and distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by noting ownership enforcement.

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 mentions 'Ownership is enforced — you can only cancel your own subscriptions,' providing important context for when to use. However, it does not explicitly state when not to use or name alternatives, which would elevate it to 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?

The description discloses substantial behavioral detail beyond the annotations: routing for company-financial vs other claims, the verdict set, the critical distinction between 'could_not_verify' and 'unsupported', and the error semantics with verification_error field. This is transparent and helps avoid misinterpretation.

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

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

The description is long but dense and well-structured, with trigger phrases up front, clear sub-sections, and every sentence adding value. It is appropriately detailed for a tool with complex routing and error semantics, though it could be slightly tightened.

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

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

Despite lacking an output schema, the description fully explains return values, verdict meanings, and error handling, making it self-contained for a caller. It covers the two claim categories, the fallback path, and the operational semantics of inconclusive 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?

Schema coverage is 100%, and the description adds meaningful nuance for tolerance_pct, explaining its override behavior, default cap of 5, and recommended settings for hallucination detection. The claim parameter is well illustrated in the schema, and the description reinforces its 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 clearly states the tool's function: natural-language claim verification against authoritative sources, with a specific verb and resource. It distinguishes itself from sibling tools by positioning itself as the fact-check/verify tool and noting it replaces 4–6 sequential calls.

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

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

Provides explicit usage guidance: 'Use whenever the agent needs to check whether something a user said is factually correct' with trigger phrase examples. It lacks explicit when-not-to-use instructions relative to sibling tools, but the consolidation note implies it is the primary verification entry point.

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