Nass

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 useful details: default model (Workers AI, free), need for _apiKey for Anthropic, and return structure (per-model {score, confidence, signals, raw_response} + combined view). 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 the core action, and no filler. Every sentence adds value. Ideal length.

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

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

All parameters are covered, return values are described (per-model scores and combined view). Without output schema, the description suffices. Could note edge cases (e.g., rate limits), but overall complete for the 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%. The description enriches parameters: explains 'entity' as thing to ask about, 'models' as supported list with defaults, '_apiKey' as passed through, 'context' as disambiguation aid. Adds value beyond raw schema.

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

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

The description uses a specific verb ('probe') and resource ('LLMs for what they know about a business/brand/product/topic') and clearly distinguishes from sibling tools like ask_pipeworx, deep_research, etc. by focusing on visibility scoring.

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

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

The description states explicit use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') but does not mention when not to use or name specific alternatives. However, the context provides clear guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: it routes to one of 5,358 tools, fills arguments, returns structured answers with pipeworx:// citation URIs, works on every tier, and is a single fast call. It does not contradict annotations, though it omits failure/error behavior.

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

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

The description is long but front-loaded with 'PREFER OVER WEB SEARCH' and every sentence serves a distinct purpose: scope, behavior, trigger phrases, examples, alternatives, and caveats. It is dense but not redundant, though a slightly tighter version could still retain all key information.

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

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

For a tool with one free-form parameter, no output schema, and a huge routing scope, the description is remarkably complete. It covers what the tool does, when to use it, when not to use it, what it returns, and provides illustrative examples. There are no significant informational gaps.

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

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

The input schema covers 100% of parameters and documents the 'question' field plus aliases. The description adds example phrasings and example queries, but no deeper parameter semantics beyond what the schema already provides. This meets the baseline for high schema coverage.

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 ask_pipeworx as the default router for factual questions, listing specific domains (SEC, FDA, FRED, stocks, weather, etc.) and giving concrete examples. It also distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by positioning itself as the default entry point.

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

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

The description explicitly says to prefer this over web search, provides trigger phrases ('what is', 'look up', 'find', etc.), and names step-up alternatives with precise conditions (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions). This is exemplary usage guidance.

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

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

The description adds valuable behavioral context beyond annotations: it is beta, may have live candidate routing improvements, currently has no active candidate so it behaves identically to ask_pipeworx, and it is a full working router with no fallback. These details are not present in the annotations, and there is 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?

Three sentences with high information density, front-loaded with the tool's identity and current status. Every sentence serves a purpose: identity, current behavior, and usage guidance. No redundancy or filler.

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

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

Given the tool is a simple router with one primary parameter, the description plus annotations and schema cover everything needed: experimental nature, current state, how to use it, and that the response shape matches ask_pipeworx. No output schema exists, but the 'same response shape' statement suffices.

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

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

Schema coverage is 100% (all 6 parameters described as aliases for 'question'), so the schema already explains parameters. The description only says 'same arguments' as ask_pipeworx, adding no new parameter semantics. A baseline 3 is appropriate when the schema handles the param details.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, a universal router, and explicitly differentiates it from the stable sibling by noting candidate routing improvements. The verb 'ask' is implied through analogy, and the resource ('universal router') is stated, making the tool's purpose unmistakable.

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

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

Usage guidance is explicit: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also contrasts with the stable router and mentions that results are compared to decide merges, providing a clear context of when this experimental variant is preferred 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description details the full behavior: routing, argument filling, fetching, extraction using only tool results, and the exact refusal reasons (not_in_source, no_tool_match, tool_error, data_truncated, llm_error). Also discloses the cost of an extra LLM call, which annotations do not capture.

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

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

Every sentence earns its place. The description is front-loaded with the key differentiator, then systematically covers routing, return shape, refusal reasons, use cases, and cost trade-off. It is a bit long but dense, making it useful without fluff.

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

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

No output schema exists, so the description correctly explains the return structure ({answer, evidence, confidence, source, fetched_at, refusal_reason}) and all refusal modes. It also covers the cost overhead and use cases, making it complete for an agent to decide when to invoke this 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% and the description does not add parameter-level detail beyond what the schema already provides. The description implies the question is natural language but the schema states this. Baseline 3 is appropriate since the schema fully documents the parameters.

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

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

The description clearly states this is a 'hallucination-resistant answer mode' that routes through the same tools as ask_pipeworx but extracts answers only from tool results. It distinguishes itself from the sibling ask_pipeworx by emphasizing grounding and high-stakes use, with a specific verb (EXTRACTS) and resource (tool results).

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

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

Explicitly states when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete examples. Also provides an exclusion: 'prefer ask_pipeworx for casual lookups' and notes the extra LLM call cost. This fully covers when/when-not with 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, and description adds extensive behavioral details: low-confidence short-circuit, closed market handling, wide-spread tradeability, resolution rules, and resolver contract inspection. 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 comprehensive but lengthy, with many examples and detailed sections. It front-loads the main purpose but could be shortened by pruning redundant examples. Still, it is well-organized with clear headers.

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

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

Given the tool's complexity and lack of output schema, the description covers input, output shapes, edge cases, safety, resolution rules, and response fields (evidence, analysis, market carry). It fully prepares an agent to invoke the tool correctly.

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

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

Schema has 100% coverage with descriptions. The description adds details: market input formats (slug, URL, question), depth levels ('quick' vs 'thorough'), and include_raw effect on response size. This adds significant value beyond schema.

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

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

The description clearly states the tool researches Polymarket bets by pulling Pipeworx data, with specific verb 'Research' and resource 'Polymarket bet'. It distinguishes from sibling tools by targeting bet-specific research, not general queries.

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

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

Explicit usage contexts are given: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It provides examples but lacks explicit when-not-to-use instructions, though context implies alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds beyond that: explains off-calendar fiscal year handling (AAPL Sep, NVDA Jan), results sorted by primary metric, and returns paired data with pipeworx:// citation URIs. No contradiction with annotations.

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

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

The description is well-structured and concise. It front-loads with common user queries, then explains behavior concisely. Every sentence adds value—no fluff. At roughly 100 words, it efficiently conveys all necessary information.

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

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

Given only two parameters, 100% schema coverage, and annotations, the description is highly complete. It explains both entity types, the metrics returned, sorting behavior, and citation URIs. However, it lacks explicit detail about the output format structure (beyond 'paired data'), which would be helpful since there is no output schema. Still, it is nearly 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%, but the description adds significant context: company type pulls 'LATEST 10-K revenue + net income + cash + long-term debt', drug type pulls 'FAERS adverse-event counts, FDA approval counts, active trial counts'. For values, it provides concrete examples (tickers for company, drug names) and constraints (2–5). This enriches the parameter understanding beyond the schema's brief descriptions.

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

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

The description starts with common user queries ('Compare X and Y', 'X vs Y') and clearly states it performs side-by-side comparison of 2–5 companies or drugs in one parallel call. It distinguishes itself from sequential single-pack lookups, making the purpose immediately obvious.

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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also details when to use each type: 'company' pulls SEC financial data, 'drug' pulls FAERS/trial data. This provides clear when-to-use and when-not-to-use guidance, replacing 8–15 sequential lookups.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description discloses account prerequisites, depth-tier behavior (gap recovery, contradiction scan), latency (15-60s, thorough up to ~90s), and return format (findings packet, gaps[], contradictions[], hop field). It even explains the failure mode (empty gaps for non-catalog topics) and semantic excerpting. 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 efficiently packed — every clause adds a distinct operational fact (auth, source universe, parallel routing, return schema, latency). It opens with the most critical constraint and sequentially builds a complete mental model. At ~200 words it could be tightened slightly, but no sentence is filler.

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

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

No output schema exists, so the description carries the burden of explaining return values — and it does so comprehensively: findings packet with verbatim evidence, confidence, source, fetched_at, citation, gaps[], contradictions[], hop field. It covers prerequisites, alternatives, multi-step iteration, and performance expectations, making it complete for a tool of this complexity.

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

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

With schema_description_coverage at 100%, the baseline is 3; the description adds real meaning to the `depth` enum by explaining what 'standard' and 'thorough' do behaviorally (gap-recovery hop, chasing leads, contradictions scan) and notes the paid-plan requirement for 'thorough'. For `question`, it supplies examples of suitable multi-part questions and clarifies broad/multi-part is preferred.

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 action ('Grounded multi-source research') over a defined resource ('Pipeworx's 1395 STRUCTURED data sources') and explicitly contrasts with siblings ('this is NOT open-web search', 'use ask_pipeworx for a single lookup'). Provides concrete examples of best-fit questions, distinguishing it from research and non-research 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 names when to use this tool ('Best for broad/multi-part questions over structured data') and when not to ('For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'). Also tells users without accounts to use ask_pipeworx instead, covering the auth-conditioned alternative. This is fully explicit when/when-not guidance.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds value by stating it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples)' and that results are 'ready to call directly, no second schema lookup needed.' This clarifies the output behavior beyond what annotations provide.

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

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

The description is efficient and front-loaded. The first sentence states the core purpose, followed by a list of domains, then details on returns and usage guidance. Every sentence serves a purpose with no 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 complexity (many sibling tools, no output schema), the description fully covers what the tool does, when to use it, what it returns, and how results can be used. It leaves no major gaps for an agent to misinterpret.

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 mentions that query accepts aliases (task, q, description, search), but this is already documented in the schema's query description. No additional semantic details beyond the schema are provided.

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.' It includes a broad list of domains and clearly distinguishes this as a discovery tool for browsing available tools, differentiating it from sibling tools like entity_profile or deep_research.

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

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

The description explicitly advises: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use guidance and implicitly suggests not using it when a single answer is needed.

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

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

Annotations already mark as read-only, idempotent, and open-world. Description adds useful behavioral details: fans across multiple sources, lists specific returned fields, notes patent source sunset and soft-fall behavior, and clarifies input constraints.

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

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

The description is dense but well-organized: starts with examples, then the elevator pitch, then detailed breakdown of sources and returns. Every sentence adds value, though slightly longer than ideal.

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 (multi-source, multi-field, no output schema), the description covers all major return components, limitations (patent sunset, name restriction), and fallback behavior. Adequate for an AI to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds extra meaning: explains that type is limited to 'company' for now, value must be ticker or zero-padded CIK (not names), and integrates with resolve_entity for names.

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

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

The description starts with many user-intent examples and clearly states the core function: 'full cross-source profile of a US public company in ONE parallel call.' It explicitly distinguishes from sibling tools like compare_entities and resolve_entity.

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

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

Explicitly instructs to 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also warns about name-only input (use resolve_entity first) and a sunsetting data source.

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

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

Description confirms destructive nature (delete) consistent with annotations (destructiveHint: true, idempotentHint: true). Adds behavioral context for use cases but lacks details on error handling or success confirmation.

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 with the action front-loaded. 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?

Simple destructive tool with no output schema; description doesn't explain return value or error behavior. Adequate but could mention what happens after deletion.

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 'key' described as 'Memory key to delete'. Description adds no additional meaning beyond schema, so baseline 3 is appropriate.

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

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

Description clearly states 'Delete a previously stored memory by key' with specific verb 'delete' and resource 'memory'. It distinguishes from siblings by naming 'remember' and 'recall'.

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 (stale context, task done, clear sensitive data) and pairs with remember/recall, providing clear context and alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral context by describing the extraction process (fetches page, extracts title/description/key links) and the output format (single text blob). No contradictions with annotations.

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

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

Two tightly written sentences plus a concise list of use cases. No redundant information. Key details are front-loaded: action, output, and purpose.

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

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

For a tool with two parameters and no output schema, the description explains the output format and process. It also provides usage context. Given annotations cover safety and idempotency, the description is sufficiently complete.

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

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

Schema coverage is 100% with both parameters described. The description does not add additional meaning beyond the schema: it repeats the URL format and notes default/max for max_links. Baseline 3 is appropriate since schema already documents parameters adequately.

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

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

Description explicitly states the tool generates a production-ready llms.txt file for any URL, specifying the verb 'generate' and resource 'llms.txt file'. It details the process: fetches page, extracts metadata, emits standard markdown. No sibling tool performs the same function, so differentiation is clear.

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

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

Description lists three concrete use cases: getting a client's site indexed, drafting for own project, or auditing competitor. This provides clear context for when to use the tool. It does not explicitly mention when not to use or alternatives, but the use cases sufficiently guide the 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 and destructiveHint; description adds return fields and parameter effect (include_inactive). No contradictions.

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

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

Two sentences with no wasted words; front-loaded with action and return fields.

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 read-only tool; description covers purpose, return fields, parameter, and usage context adequately.

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

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

Schema coverage is 100%, and description adds context that default is false. No additional syntax details needed 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 the tool lists the caller's active subscriptions with a specific verb and resource, and distinguishes from siblings like subscribe and unsubscribe.

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

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

Provides explicit use cases: reviewing monitored subscriptions before adding more or finding an id to cancel. Does not mention when not to use, but context with siblings provides clarity.

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. Description adds that it's 'quick access to major crop survey data', but doesn't detail return size, pagination, or rate limits. 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?

Two concise sentences, front-loaded with the action, no unnecessary words. Efficiently communicates purpose.

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

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

Adequate given existence of output schema and clear schema examples. Could mention default behavior (national/year) but not essential. Complete enough for agent invocation.

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

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

All 5 parameters have full schema descriptions (100% coverage). The description adds no additional meaning beyond the schema, so baseline score applies.

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

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

Description clearly states verb 'Get' and specific resources: crop yields, production totals, planted/harvested acreage. Distinct from sibling tools like nass_crop_progress (progress) and nass_prices (prices).

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

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

No explicit guidance on when to use vs alternatives like nass_query or nass_crop_progress. Usage is implied by name and description but not clarified.

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 behavior. The description adds further context by disclosing that condition queries return a condition_summary with the latest national ratings plus good_or_excellent_pct, and that omitting stat_category returns both categories. This is meaningful behavioral detail beyond annotations.

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

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

The description is three sentences, front-loaded with the core resource, then provides targeted usage details. Every sentence earns its place with no redundancy or filler.

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

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

With an output schema present and annotations covering safety, the description adds the critical nuance of condition_summary vs good_or_excellent_pct and the stat_category default behavior, making it complete for the tool's complexity. No key gaps remain.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the semantics of stat_category with concrete examples ('what % of corn is good or excellent') and clarifying that omitting it returns both categories, which is not obvious from 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 provides weekly USDA crop progress and condition data by crop and state. It distinguishes itself from sibling NASS tools (production, livestock, prices) by subject matter even without naming them. The explicit mention of CONDITION and PROGRESS categories adds specificity.

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

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

The description gives explicit usage guidance on when to use stat_category='CONDITION' vs 'PROGRESS', including example queries and explains default behavior (both returned if not narrowed). It does not explicitly exclude alternative tools, but the resource scope 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, and destructiveHint=false, fully covering safety and side effects. The description adds no new behavioral context but 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 two sentences, directly states the purpose, and contains no superfluous words. It is well-structured 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?

Given the presence of a detailed schema, comprehensive annotations, and an output schema, the description adequately covers the tool's role. It could mention default values or data scope, but the schema already provides defaults.

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 does not add additional parameter details beyond what the schema provides.

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

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

The description clearly states the tool retrieves US livestock inventory, slaughter, and production data by species, state, and time period. The verb 'Get' and resource 'livestock data' are specific. However, it does not differentiate from sibling tools like nass_crop_production or nass_query, which could also provide related 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?

No guidance is provided on when to use this tool versus alternatives such as nass_query or nass_prices. The description lacks explicit context for selection among similarly named NASS tools.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool provides prices received by US farmers, which is useful context but does not disclose additional behavioral traits like data update frequency, aggregation, or pagination. The description 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?

Two concise sentences front-load the key purpose and scope. No redundant or filler content. Every word earns its place.

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

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

Given the presence of an output schema (true), the description does not need to explain return values. It adequately covers the filtering dimensions and intent. However, it omits mention of the required API key, but that is already captured in the input schema. The description is mostly complete for a read-only data retrieval tool with good annotations.

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%, with each parameter having a description. The description restates that it filters by commodity, state, and year but adds no new semantic detail beyond the schema. The baseline of 3 is appropriate as the description neither adds nor detracts.

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 retrieves prices received by US farmers for crops and livestock, specifying dimensions (commodity, state, year). The verb 'Get' and resource 'prices' are explicit, and the tool is distinct from sibling tools like nass_crop_production or nass_query which cover other data types.

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 use for tracking agricultural price trends but does not explicitly state when to prefer this over siblings (e.g., nass_crop_production for production data, nass_livestock for livestock-specific data). No exclusions or alternative guidance provided.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds minimal behavioral context beyond stating return data types; it does not disclose rate limits, error handling, or query limitations.

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

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

The description is two sentences, front-loaded with purpose and includes a concrete example. It is efficient with no unnecessary words, though the example's mention of 'state_fips' conflicts with the schema's 'state' parameter.

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 10 parameters and an output schema, the description is too brief. It does not explain return format, pagination, or how multiple parameters interact. Annotations cover safety but the description lacks depth for a complex query 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 parameter descriptions. The description provides a single example but does not systematically explain parameter usage or constraints. Baseline 3 is appropriate; description adds marginal value.

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

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

The description clearly states the tool searches USDA agricultural statistics by commodity, statistic, geography, and year, with a concrete example. It distinguishes from broader search tools but does not explicitly differentiate from sibling tools like nass_crop_production or nass_livestock, which are more specific.

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 no guidance on when to use this tool versus its more specific siblings (e.g., nass_crop_production). It lacks explicit when-not-to-use or alternative recommendations.

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

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

Annotations are all false, but description adds critical behavioral details: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota. 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?

Single paragraph with clear, front-loaded sentences. No wasted words. Efficiently covers purpose, usage, constraints.

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 nested objects and no output schema, description adequately explains input behavior, rate limits, quota, and what to avoid. Could mention anonymity but not necessary.

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 schema already describes parameters. Description adds usage context for the type enum and message content (be specific, 1-2 sentences). Adds value beyond schema.

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

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

Description clearly states it's for telling the Pipeworx team about bugs, missing features, data gaps, or praise. Uses specific verbs like 'tell' and 'describe' and identifies the resource ('Pipeworx team'). Distinguishes from sibling tools, which are query/analysis 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 (bug, feature/data_gap, praise) and what not to do (don't paste end-user prompt). Mentions daily team review and roadmap impact. No direct alternatives given, but sibling tools are unrelated.

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. Description adds valuable context: data source (CF analytics-engine), privacy (no PII), and caching (5min-1h). 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?

Well-structured with bullet points and clear sections. Front-loaded with core functionality. Every sentence adds value—no wasted words. Approximately 70 words, efficiently communicating purpose, use cases, and behavioral traits.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: what is returned, when to use, data source, privacy, caching. No gaps remain.

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

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

Schema has 100% coverage with a clear enum and description. Description reinforces the window options but does not add significant new meaning beyond the schema. Baseline 3 is appropriate as the schema already 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?

Clearly states it returns top tools, packs, and call volume for trending data on Pipeworx, with specific verb 'Returns' and resource 'trending data'. Distinguishes from sibling tools by focusing on aggregated agent usage rather than queries or research.

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

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

Provides three explicit use cases: discovering hot data sources, confirming canonical tools, and aligning use cases with agent needs. Also explains window selection trade-offs (short vs. long windows). While no direct alternatives are named, the use cases give clear context for when to use this tool over 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 read-only, idempotent, open-world. Description adds rich behavioral details: algorithm steps, semantic similarity threshold (0.30 Jaccard), placeholder filtering, partition check, fill check against CLOB depth, and realizable edge warning. No contradictions with annotations.

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

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

The description is long but well-structured with clear sections (mode descriptions, semantic anchor, partition filter, response, fill check). Every sentence adds value, though some density could be reduced. Front-loaded with purpose and mode selection.

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

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

Given the tool's complexity (two modes, multiple internal checks, output structure), the description covers all aspects: algorithm, filters, response fields, fill check, and links to sibling tool for custom sizing. No output schema, but response is adequately described.

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

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

Schema coverage is 100%, and the description adds substantial meaning: explains the two modes, provides example values (slugs, URLs, seed questions), and describes the behavior for each parameter (trending scan with no args, event triggers partition_check, topic triggers cross-event scanning).

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

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

The description clearly identifies the tool as finding arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) with specific use cases, and the title+context differentiates it from sibling tools like polymarket_edges.

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

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

Provides explicit guidance: no args for trending scan, event for specific market, topic for cross-event scanning. Recommends event mode for specific markets. Does not explicitly state when not to use, but the context of modes and sibling tools gives adequate direction.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds substantial behavioral context: it explains the three model families, edge calculation details (e.g., slippage, Kelly fractions), response structure (by_segment with fed_candidates and diagnostics), caching at KV level with 1-hour ttl, and conditions for tradeable-edge filters. 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 comprehensive but verbose, spanning multiple paragraphs with very detailed algorithmic explanations. While well-structured with sections, it could be more concise for quick agent parsing. Every sentence adds value, but the length may slow down comprehension.

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

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

Given the complexity (model families, multiple segments, filters) and that there is no output schema, the description thoroughly covers the response structure, diagnostics, caching, and edge cases (e.g., Fed data unreliability). It leaves little ambiguity about what the tool does and returns.

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

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

All 9 parameters have descriptions in the Input Schema (100% coverage), so baseline is 3. The description adds value by grouping parameters into conceptual categories like 'Tradeable-Edge KNOBS' and explaining their interplay (e.g., min_liquidity and max_spread_pp drop unrealizable edges). 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 scans Polymarket markets to find opportunities where Pipeworx data disagrees with market price, using a specific verb 'scan' and resource 'top Polymarket markets'. It is highly specific and differentiates from siblings by detailing model families and segments, making the purpose unambiguous.

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

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

The description explicitly states it is built for 'what should I bet on today' and helps discover opportunities without paging hundreds of markets. It provides usage guidance via tradeable-edge knobs and explains when Fed bets are included with a caveat. However, it does not directly mention when to avoid this tool or compare to sibling tools like polymarket_arbitrage, but the use case 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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details: decay is computed from daily closes (not intraday), snapshots are written on cache-miss, and gaps indicate no scan. No contradictions.

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

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

The description is dense but front-loaded with the core question. Every sentence adds value, though it could be slightly more concise. Structure is logical with LIMITS at the end.

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

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

With no output schema, the description fully details the response format: tracked[], expired[], snapshot_dates[]. It covers all necessary aspects for an agent to use the tool correctly, including edge cases like gaps and TTL.

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

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

Schema covers both parameters completely. The description adds context: default values, max for days, and purpose of window. It enhances meaning by linking parameters to the telemetry concept.

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 provides 'edge persistence and decay telemetry' and answers a specific question about edge longevity. It distinguishes itself from the sibling tool polymarket_edges by focusing on history and decay rather than current edges.

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

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

The description explains when to use this tool by contrasting fresh vs old edges, and notes limitations like 60-day TTL and snapshot gaps. However, it does not explicitly mention alternatives or when not to use it, but context is strong.

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 provides extensive behavioral context beyond annotations: it explains how it walks the order book ladder, calculates VWAP fill price and slippage, returns verdicts (clean/degraded/cannot_fill), and details risks of partial fills and forced directional risk. Annotations (readOnlyHint, idempotentHint, destructiveHint=false) are consistent and do not contradict.

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

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

The description is well-structured with clear sections for single-market and basket modes, and usage guidance. However, it is verbose in places (e.g., repeating 'REQUIRES one of' and listing return fields) and could be slightly more concise, though the complexity justifies the length.

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

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

The description covers all aspects: dual modes, parameter semantics, behavior, return values (including verdict, slippage, capture ratio, thin legs, etc.), risks, and usage context. Despite lacking an output schema, it documents all key return fields, making it fully self-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?

Input schema has 100% description coverage with good parameter descriptions, so baseline is 3. The description adds extra meaning by clarifying the auto side logic for basket mode, the dual interpretation of size_usd (spend vs target proceeds vs settlement notional), and the requirement for exactly one of market or event.

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

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

The description clearly states the tool performs a realizable-vs-theoretical edge check against live CLOB order-book depth. It specifies two distinct modes (single-market and basket) with explicit verbs like 'check', 'walks the ladder', and 'returns', and distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

The description explicitly tells when to use this tool: before acting on polymarket_arbitrage SELL/BUY-EVERY-LEG signals or polymarket_edges trades above ~$500. It also warns against misuse by explaining that theoretical overround on thin books is not capturable and partial basket fills can convert an arb into an unhedged directional position.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, safe. Description goes far beyond by detailing compatibility_warning conditions (bet-shape mismatch, semantic mismatch), temporal alignment impact, and skipped leg comparisons (cross-type/subtype). No contradiction with annotations; in fact, it enriches them.

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

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

Description is long but well-structured with sections (TWO MODES, RESPONSE, SAFETY FIELDS) and front-loaded with the core purpose. Each sentence contributes value; the length is justified by tool 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, description thoroughly covers response fields (raw probabilities, spread, safety fields like compatibility_warning, temporal_alignment, skipped counters). Agents get a complete picture of what the tool returns and how to interpret warnings.

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 description reiterates parameter values with examples. Description adds meaning by explaining that explicit tickers override topic-mapped sides. Provides good context beyond the raw 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?

Clearly states the tool calculates cross-venue spread between Kalshi and Polymarket for the same resolving question. Specifies two modes (topic shortcuts and explicit tickers) and distinguishes from siblings like polymarket_arbitrage. The purpose is precise and unambiguous.

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

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

Provides explicit guidance on when to use topic mode vs explicit mode, and warns that most pre-mapped topics return compatibility warnings, so the agent should not assume tradeability. Missing explicit instruction on when NOT to use this tool vs alternatives like polymarket_arbitrage, but the cross-venue nature implies that.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds scoping information (IP, key hash, account ID) and clarifies non-destructive behavior. No contradictions.

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

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

Two sentences front-load the main function and usage, then add secondary details. Every sentence earns its place with zero waste.

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

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

Tool has 1 optional parameter and no output schema. Description covers core behavior, scoping, and pairing with siblings. Could mention return format (e.g., value string vs list of keys) but not critical.

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

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

Schema covers 100% of parameters with description for 'key'. Description adds context that omitting key lists all saved keys, which is useful 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 the tool retrieves a value saved via remember or lists all keys if argument omitted. It distinguishes from sibling tools (remember, forget) and specifies the exact resource and action.

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: 'look up context the agent stored earlier' versus re-deriving. Mentions pairing with remember and forget, but does not explicitly exclude other tools or provide 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 indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it returns specific fields (source, citation_uri, payload), explains mark_read behavior to control subsequent calls, and notes that polling is acceptable. No contradictions; the description enriches understanding 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 four sentences long, each adding essential information. The first sentence states the main action and purpose. Subsequent sentences add return fields, filtering, mark_read behavior, and an alternative endpoint. No redundant or extraneous content.

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

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

Despite lacking an output schema, the description specifies key return fields (source, citation_uri, payload). All parameters are addressed, and the description covers filtering, pagination (limit), and state management (mark_read, unread_only). The mention of an alternative endpoint adds completeness. Slight gap: no mention of authentication or rate limits, but annotations likely cover safety.

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

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

Schema coverage is 100% with descriptions for all 5 parameters. The tool description adds value by clarifying 'type' filters subscription type, providing the valid range for 'limit' (1-200, default 50), specifying that since is an ISO timestamp for 'fired_at', and explaining the mark_read and unread_only flags more concretely. This goes beyond the schema descriptions.

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

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

The description clearly states the tool retrieves recent alerts from a subscription feed. It mentions what is returned (source, citation_uri, payload) and filtering options. However, it does not explicitly differentiate from sibling tools like 'recent_changes' or 'list_subscriptions', though the context of alerts versus changes or subscriptions is implicit.

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 concrete usage guidance: filtering by type and/or since, setting mark_read to manage read state, and noting that polling works fine. It also mentions an alternative endpoint for scripts/dashboards. It does not explicitly state when not to use, but the guidance is clear enough for typical use.

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

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

Annotations declare readOnly, idempotent, non-destructive. Description adds sources, fallback logic, soft-fail for USPTO, and output structure (changes[] grouped by source, total_changes, citation URIs). 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?

Single paragraph with no wasted words, front-loaded with query examples, structured logically from purpose to parameters to return format.

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?

Even without output schema, description explains return format clearly. Covers all necessary aspects for correct invocation and interpretation, given the tool's complexity.

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

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

Schema coverage is 100%, and description adds context: 'since' format with recommended '30d', 'type' limited to 'company', 'value' example with ticker/CIK. Adds 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 provides a change feed for a company from SEC EDGAR, GDELT/GNews, and USPTO. It differentiates from sibling 'entity_profile' by contrasting window-based changes vs. static profile.

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 examples of queries like 'What's new with X' are given, with a clear directive to use 'entity_profile' for static profile regardless of window. Fallback behavior (GNews when GDELT fails) is also noted.

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 idempotentHint=true and destructiveHint=false. The description adds beyond: per-user scoping, authenticated vs. anonymous persistence (24 hours). 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?

Each sentence adds value, starting with the primary purpose. The description is concise without fluff, front-loading the key action and usage.

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

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

Given only 2 required params and no output schema, the description covers when to use, persistence, and pairing with recall/forget. It is fully sufficient for an AI agent to understand the tool's role.

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

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

Schema coverage is 100%, so the baseline is 3. The description provides key-value pair context and examples of keys (e.g., 'subject_property'), but does not significantly expand on parameter meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later.' It provides specific examples (e.g., 'a resolved ticker, a target address, a user preference') and distinguishes it from siblings like 'recall' and 'forget'.

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

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

The description explicitly says 'Use when you discover something worth carrying forward' and pairs with recall/forget. It provides context on scoping and persistence. However, it lacks explicit 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: it explains that each call cascades through several lookup endpoints, replaces 2-3 manual lookups, and returns specific detail like citation URIs. This goes beyond the annotations.

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

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

The description is concise for the amount of information conveyed; it front-loads the core purpose with example queries and then details supported types and returns. It could be slightly shorter but is well-organized and 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 no output schema, the description thoroughly explains return values for both entity types, including example outputs and citation URIs. It also notes the internal cascading behavior. This is complete for an agent to understand what the tool does and what to expect.

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 examples for 'value' (ticker, CIK, name for company; brand/generic for drug) and clarifies what each 'type' returns (ticker+CIK+company_name+URI for company; RxCUI+ingredient+brand for drug). This adds significant meaning beyond the schema.

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

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

The description uses specific verbs ('resolve') and resources ('a user-spoken NAME to the canonical/official identifier'), and clearly distinguishes from sibling tools by stating it's the first tool to use when a name is given but an ID is needed. Examples of queries like 'What's the ticker for…' make the purpose immediately clear.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID,' providing strong guidance on when to use the tool. It does not explicitly state when not to use it or name alternative tools, but the context is clear and the supported types are listed.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral context: it internally calls ai_visibility_check, returns ranked list with score, confidence, signal density. 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?

Three sentences, front-loaded with purpose, efficient and no wasted 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?

Given no output schema, the description covers the return format (ranked list with score, confidence, signal density). It sufficiently describes inputs and outputs for an agent to use the tool effectively, though error conditions are not mentioned.

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 value beyond the schema by explaining that the first entry is treated as the 'subject' for narrative and rest are competitors, and clarifies the relationship between models and _apiKey.

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

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

The description uses specific verbs and resources ('Compare AI visibility across multiple entities side-by-side') and clearly distinguishes from siblings like ai_visibility_check which checks a single entity. It provides a concrete example and details the ranking process.

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 clear use case ('competitive AI-marketing audits') and an example question, but does not explicitly state when not to use this tool or mention alternative tools among the 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds valuable behavioral details: internal composite fan-out, partial failures with graceful degradation, bundlephobia's first measurement delay of 5-30s, and sources_failed field.

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 well-structured with critical info front-loaded. Each sentence adds value, covering purpose, usage, output format, ecosystem scope, and failure behavior. Slightly dense but without fluff.

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

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

Despite no output schema, the description lists all return fields and details. It also covers partial failures, timing, and ecosystem scope. For a composite tool that aggregates complex data, this is comprehensive.

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

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

Input schema has 100% description coverage. The description does not add significant meaning beyond the schema's parameter descriptions. It mentions that version defaults to latest, which is already in the schema.

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

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

The description clearly states it's a composite check for evaluating an npm package, fanning out across deps.dev and bundlephobia. It distinguishes itself from all sibling tools, none of which are npm package evaluation 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 says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also indicates NPM ecosystem only, with other ecosystems handled by deps.dev:version directly. Lacks explicit 'when not to use' but provides clear context.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals the embedding model (BGE-base-en), window size (500-char overlapping), character cap (200K chars with truncation and flag), and return format (passages with offsets and similarity scores). No contradiction with annotations.

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

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

The description is a single paragraph but front-loads the core action and then adds details. Every sentence provides distinct information (purpose, when to use, pairing, technical details, limitations). Slightly dense but no wasted words.

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

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

Despite no output schema, the description compensates by explaining return values (top-N passages with character offsets and similarity scores) and technical limits (cap, truncation flag). It covers all needed context for correct invocation.

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

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

Schema coverage is 100%, but the description adds value by providing default (limit=5), range (1-20), and examples for the query parameter. It also repeats the max chars for text, reinforcing the schema's 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 performs 'Semantic search INSIDE a fetched record' with a specific verb ('search') and resource ('record text'). It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded and contrasts with fetching full documents.

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

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

The description explicitly says 'Use when the record is too big to cram into the prompt' and provides a concrete use case. It also references a sibling tool (ask_pipeworx_grounded) for grounding. However, it does not explicitly list when not to use or compare to alternatives like full-text search.

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 details delivery channels, constraints (e.g., SMS cap, webhook signing), and the return of a subscription id. However, it contradicts the idempotentHint annotation by implying each call creates a new subscription without mentioning deduplication or idempotent 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 front-loaded with the core purpose, followed by prerequisites and detailed type/delivery information. It is thorough but not overly verbose, with each sentence adding 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 the tool's complexity (3 parameters, nested objects, no output schema), the description covers types, delivery options, and return value adequately. It mentions one-time webhook secret but could be improved by addressing idempotency and error states.

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

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

The description adds significant meaning beyond the schema by providing type-specific examples, item code explanations, and detailed delivery channel behavior (e.g., webhook signature verification). Schema coverage is 100%, but the description enriches understanding.

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

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

The description clearly states the tool's purpose: 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' It specifies supported types and their parameters, distinguishing it from sibling tools like list_subscriptions and unsubscribe.

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

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

The description mentions a prerequisite (Pipeworx OAuth account) and provides context for when to use the tool. It does not explicitly state when not to use it or list alternatives, but the sibling tools imply this is the only creation 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 already declare it read-only, idempotent, and non-destructive. The description adds that it returns category-bucketed examples with tool+argument shape, and behavior with/without topic argument.

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

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

The description is well-structured with a clear purpose, examples, and usage instructions. Slightly verbose but 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?

No output schema but description explains return type (category-bucketed examples). Annotations cover safety. Covers parameter behavior adequately 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 coverage is 100% with the topic parameter description listing values. The description adds context on how to omit for full spread and focus with topic, going 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 the tool returns category-bucketed example questions and serves as the onboarding entry point. It distinguishes itself from sibling tools by specifying when to use it first.

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 to use this tool first when unfamiliar with Pipeworx and to learn how to call meta-tools. Provides clear usage context and examples.

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

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

Discloses that rows are deactivated (not deleted) and historical events remain via recent_alerts, adding value beyond annotations which only hint idempotency and non-destructiveness.

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 action, efficient and no wasted words.

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

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

Given simple tool (1 param, no output schema), description thoroughly explains effect and links to relevant sibling tool recent_alerts for historical events.

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

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

Schema covers 100% of parameters (id described as uuid returned by subscribe). Description adds no extra parameter details, but baseline is satisfied.

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

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

Clearly states action ('Cancel') and resource ('subscription by id'). Distinguishes from sibling tools like subscribe and list_subscriptions.

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

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

Explicitly states ownership enforcement ('only cancel your own subscriptions'), guiding when to use. Lacks explicit mention of alternatives but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: the two processing pathways (fast path for SEC data vs. grounded pipeline), the verdict types (confirmed, refuted, etc.), and the inclusion of exact percent-delta math for financial claims. 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. It front-loads with example phrases, then explains the two paths and returns. Every sentence adds value, and it avoids unnecessary repetition. For a tool with moderate complexity, this is appropriately sized.

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 lack of output schema, the description explains the return verdicts and citation. It covers the main functionality, the two processing paths, and the parameter semantics. For a tool with only 2 parameters and no nested objects, this is complete and leaves no major gaps.

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

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

The input schema has 100% description coverage for both parameters, so the baseline is 3. The description adds value by explaining that 'claim' is a natural-language factual claim with examples, and 'tolerance_pct' can override the default tolerance implied by the claim wording (capped at 5%). This goes beyond the schema's 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: verifying factual claims against authoritative sources. It provides explicit usage cues like 'fact check', 'verify the claim that...', and distinguishes itself from siblings by detailing the two processing paths (SEC EDGAR for financial claims, grounded pipeline for others). The verb 'validate' combined with the resource 'claim' is specific and unambiguous.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates between company-financial claims and other factual claims, guiding when each path triggers. While it doesn't explicitly list when NOT to use it, the context is clear enough given the sibling tools like ask_pipeworx_grounded.

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