Noaa Spc

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

Annotations already cover read-only, idempotent, non-destructive, and open-world nature. The description adds value by detailing return structure (per-model score, confidence, signals, raw_response, combined view) and model-specific behavior (default free model, BYO key for Anthropic), which is beyond annotation scope.

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 efficiently cover purpose, default behavior, optional enhancement, and return format. Front-loaded with the main action and no superfluous 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?

Given no output schema, the description adequately describes return fields and use cases. Lacks mention of latency or caching, but overall sufficient for a probe 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 coverage is 100%, so baseline 3. The description reinforces schema details (default model, _apiKey for Anthropic) and adds minor context like 'free' and 'BYO key', but does not significantly expand meaning beyond what the schema already provides.

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

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

The description clearly states it probes LLMs to score visibility (0-100) for a given entity. The verb 'probe' and resource 'LLMs' are specific, and the scope (business/brand/product/topic) is well-defined. Distinguishes from siblings by focusing on AI visibility scoring.

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

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

Provides clear context for use (AI-marketing audits, pre-launch checks, competitive monitoring) and notes default model vs. Anthropic with API key. However, does not explicitly exclude alternatives or mention when not to use this tool relative to siblings like 'scan_competitor_ai_presence'.

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 value by explaining the routing behavior across 5,245 tools, filling arguments, and returning structured answers with 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?

The description is long but well-structured and front-loaded with the key directive 'PREFER OVER WEB SEARCH'. Each sentence provides useful information, though some minor trimming could be possible. 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 no output schema, the description adequately explains return format ('structured answer with stable pipeworx:// citation URIs'). It covers the tool's role as default entry point and mentions the large tool set. Complete for the tool's complexity.

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

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

Schema coverage is 100%, with all parameters (question and aliases) described. The description does not add significant new meaning beyond the schema; it mentions 'fills arguments' generally but no specific parameter details. Baseline 3 is appropriate.

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

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

The description clearly states the tool routes questions to a large set of tools for factual data, with specific verb 'ask' and resource 'Pipeworx'. It distinguishes from sibling tools like ask_pipeworx_grounded and deep_research by explaining when to use each.

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

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

Explicitly says 'PREFER OVER WEB SEARCH' and provides detailed when-to-use rules: factual questions about real-world entities, events, or numbers. It also specifies when to step up to alternatives (ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad questions). Includes concrete 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?

Annotations declare read-only, idempotent, etc. The description adds significant behavioral context: beta status, candidate routing improvements, current inactive state, and that it's a full working router. No contradiction with annotations.

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

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

The description is somewhat lengthy but each sentence adds value. It is front-loaded with the beta nature and provides necessary context without excessive redundancy.

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

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

Given the tool's complexity as a universal router with beta status, the description covers its state, relationship to stable version, current behavior, and usage recommendation. No output schema needed due to implied similarity with ask_pipeworx.

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

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

Schema coverage is 100% with aliases fully described. The description adds no additional meaning about parameters beyond what the schema provides. Baseline score of 3 applies.

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

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

The description clearly identifies this as a beta version of ask_pipeworx with identical functionality and routing improvements. It distinguishes from siblings by specifying it is the experimental edge version.

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

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

It explicitly tells when to use it: 'when you want the newest routing' and compares to the stable router. It also notes that currently it matches ask_pipeworx exactly, providing clear context for usage.

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

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

Beyond annotations (readOnly, idempotent, etc.), the description details the exact return schema including refusal_reason values, the extra LLM call cost, and the constraint of using only tool result data. 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?

Front-loaded with key phrase and well-structured, but somewhat lengthy. Every sentence adds value, though some technical details could be condensed without loss.

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 tool complexity, lack of output schema, and multiple siblings, the description fully covers purpose, usage, behavior, parameters, and return format. It is complete and informative.

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 descriptive parameter names and descriptions. The description adds value by listing all aliases and clarifying they are interchangeable, but the schema already explains each.

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 is a 'hallucination-resistant answer mode for high-stakes reads' and explains the extraction behavior. It distinguishes itself from sibling tools like ask_pipeworx by emphasizing use when answers must be cited or acted upon.

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 provides when-to-use (high-stakes, quoted/cited answers) and when-not-to-use (casual lookups, prefer ask_pipeworx). Also mentions cost trade-off, giving 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?

The description goes well beyond the annotations (which already indicate read-only, idempotent, non-destructive behavior) by detailing fan-out behavior, response shapes, resolver contracts, safety short-circuits (low-confidence, closed markets), spread warnings, and resolution-rule risk. This provides rich behavioral transparency without contradicting annotations.

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

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

The description is very long and dense, packing extensive details into a single paragraph. While front-loaded with the core purpose, the subsequent details (classifiers, fan-out examples, response shapes, etc.) are numerous and could be better structured (e.g., bullet points). Some information, like extensive fan-out examples, might be better placed in separate documentation. However, every sentence adds value for a complex tool.

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

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

Despite the absence of an output schema, the description thoroughly explains return values (result.market, result.analysis, result.evidence, resolver contract, parent event, news fields) and edge cases (low confidence, closed markets, wide spreads, resolution-rule risk). It covers all aspects necessary for an agent to understand and invoke the tool correctly.

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

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

Input schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it reiterates input formats (slug, URL, question text) already captured in the schema. The description does not elaborate on parameter semantics further, so score remains at 3.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the verb ('Research'), resource ('Polymarket bet'), and action ('pulling Pipeworx data'). This distinguishes it from siblings like 'polymarket_edges' or 'polymarket_arbitrage' by emphasizing a one-call comprehensive research approach.

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

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

The description provides explicit usage scenarios: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' This gives clear context for when to invoke the tool. While it does not explicitly state when NOT to use it or list alternatives, the scenarios are specific enough to 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 declare readOnlyHint, idempotentHint, destructiveHint false. Description adds significant behavior: pulls latest 10-K data, handles off-calendar fiscal years, sorts by primary metric, returns 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?

Description is dense but front-loaded with trigger examples. One paragraph covers purpose, usage, data sources, and sorting. Could be broken into structured sections, 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?

Given 2 params, no output schema, and good annotations, the description is complete: it covers what, when, how, and what data. Lacks details on output structure, but the URI references suffice for agent understanding.

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

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

Schema coverage is 100%, but description adds meaning beyond schema: explains type enum with data sources (SEC EDGAR vs FAERS), values array with example tickers/drug names and max count. This helps agents construct correct calls.

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 purpose is clearly articulated with multiple trigger phrases ('Compare X and Y', 'X vs Y', 'rank these companies'). It specifies exact verb+resource: side-by-side comparison of 2–5 companies or drugs in one call, and explicitly distinguishes from sequential single-pack lookups.

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

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

The description explicitly instructs to prefer this tool over sequential lookups when comparing entities. It provides concrete use cases (e.g., 'which is bigger') and separates company vs drug types. Missing explicit guidance on when not to use (e.g., >5 entities), but overall 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 convey read-only, idempotent, and non-destructive behavior. The description adds no new behavioral traits beyond the format, but it does not contradict annotations. With strong annotations, the description is adequate.

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 concise sentence, front-loaded with the key information. However, 'Day-N' is slightly cryptic and could be replaced with 'Day 1-3' for clarity. No wasted words.

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

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

For a simple tool with one optional parameter, rich annotations, and an output schema, the description is minimally sufficient. It omits what a convective outlook represents (e.g., risk categories) and update frequency, but the output schema likely fills gaps.

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

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

Schema coverage is 100% with a detailed description of the 'day' parameter (values 1, 2, 3, default 1). The description only says 'Day-N' which adds no extra 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?

The description clearly states the tool returns a 'Day-N convective outlook GeoJSON', identifying the resource (convective outlook) and format. It is not a tautology and distinguishes from siblings like mesoscale_discussions or storm_reports, though 'Day-N' could be more explicit.

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 like mesoscale_discussions, storm_reports, or watches_active. The agent receives no help in choosing among related weather 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?

Beyond annotations (readOnlyHint=true, openWorldHint=true, etc.), the description adds rich behavioral context: account tiers, output format (findings packet with verbatim evidence, confidence, source, fetched_at, citations), depth-level mechanics (gap recovery, contradictions), semantic excerpting, and expected latency (15-90s). 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 well-structured and front-loaded with critical info (account requirement, alternative tool). Every sentence serves a purpose, though some details (e.g., 'semantically excerpted') could be tighter. Overall, it's informative without being wasteful.

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 (1369 sources, 5245 tools, no output schema), the description is thorough: it explains output structure, depth behaviors, edge cases (current news → empty gaps), iteration mechanics, and expected latency. It compensates fully for missing output schema and complex parameter semantics.

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

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

Schema description coverage is 100%, but the description adds significant nuance: for 'depth', it explains what each enum value does (quick=3 facets, standard=5 with gap recovery, thorough=8 with full iterative hop); for 'question', it clarifies that broad/multi-part questions are acceptable. This adds meaning beyond the basic 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 explicitly states the tool performs grounded multi-source research across 1369 structured data sources in one call, distinguishing it from open-web search and sibling tools like ask_pipeworx. The verb 'research' and resource 'structured data sources' are clearly identified, and the scope is well-defined.

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

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

The description provides explicit guidance on when to use this tool (broad/multi-part questions over structured data) and when to use alternatives (single lookup or current news → ask_pipeworx). It also notes the account requirement and directs users to ask_pipeworx if not signed in.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that results are ready to call directly with curated examples, no second lookup needed—valuable 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?

Description is moderately long but every sentence adds value—domain list, return details, usage instruction. Could be slightly tighter but 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?

For a discovery tool with 30+ siblings, description fully covers purpose, return contents (top-N tools with full schemas), limit parameter, and usage context. No output schema, but description explains 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% with descriptions for each parameter. Description explains aliases (q, task, search, description) and gives two concrete examples, adding 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?

States verb 'Find tools by describing the data or task', lists many specific domains (SEC, FDA, etc.), and distinguishes from siblings by highlighting that it returns ready-to-call results with full schemas.

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

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

Explicit guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Clearly tells when and why to use it over direct tool calls.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses fan-out across multiple sources, specific return fields, patent sunset (May 2025, soft-fails), news fallback mechanism, and limitations. 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 somewhat dense. It front-loads with examples and a clear directive, but the paragraph could be more scannable with bullet points. Every sentence adds value, so slightly verbose but justified.

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

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

No output schema exists, so the description must detail return values. It does so thoroughly: cik, company_name, recent_filings (up to 5 with URIs), fundamentals (specific fields, sorted), patents (with sunset), news (fallback), LEI. Limitations are also noted.

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

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

Schema coverage is 100%. The description adds meaning by explaining the 'type' enum (only 'company' supported), the 'value' format (ticker or zero-padded CIK) with examples, and explicitly notes that names are not supported.

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 like 'full cross-source profile' and lists data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and return fields. It distinguishes itself from siblings by stating 'ALWAYS PREFER over chaining single-pack... lookups when the user asks for a holistic view.'

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

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

Explicit guidance: 'ALWAYS PREFER over chaining... when the user asks for a holistic view.' Also clearly states supported inputs (ticker or CIK) and unsupported (names), directing to use 'resolve_entity' first if only a name is available.

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 set destructiveHint=true and idempotentHint=true. Description confirms deletion without contradicting annotations. No additional behavioral details like auth needs or side effects, but annotations cover the key traits.

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 no fluff: action, usage, pairing. Front-loaded with core purpose. Every sentence earns its place.

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

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

For a simple 1-param tool with no output schema, the description covers purpose, usage, and pairing with siblings. No gaps given tool complexity.

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

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

Schema coverage is 100%, so baseline 3. The description adds 'by key' which matches the parameter, but the schema already describes 'Memory key to delete'. No additional semantic 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 states 'Delete a previously stored memory by key', which is a specific verb and resource. It also mentions pairing with 'remember' and 'recall', clearly distinguishing this as the deletion counter-part.

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

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

Explicitly lists three usage scenarios: stale context, completed task, clearing sensitive data. Lack of explicit 'when not to use' is minor; the guidance 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 discloses the tool fetches the page, extracts title/description/key links, and emits standard llms.txt markdown, which goes beyond annotations that already indicate read-only, idempotent, non-destructive behavior. It adds context about the process and output format.

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, consisting of three clear sentences. It is front-loaded with the main purpose and immediately provides actionable detail, with no unnecessary words or repetition.

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

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

Given the simplicity of the tool (2 parameters, no output schema), the description adequately covers what the tool does, its output format, and usage scenarios. It could mention potential limitations (e.g., requiring public URLs), but overall it is complete for effective usage.

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

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

Schema coverage is 100% with both parameters ('url' and 'max_links') described in the schema. The description does not add additional meaning or details about parameter usage beyond what the schema provides, so it meets the baseline of 3 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 states the tool generates a production-ready llms.txt file for any URL, specifying verb ('Generate'), resource ('llms.txt file'), and context ('for any URL'). It distinguishes the tool from siblings by focusing on a specific output format and use case, such as AI crawler indexing.

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

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

The description provides explicit usage scenarios ('getting a client's site indexed by AI', 'drafting llms.txt', 'auditing how an AI crawler would see a competitor'), but does not explicitly contrast with sibling tools like 'ai_visibility_check' or 'scan_competitor_ai_presence'. The guidance is clear but lacks exclusion criteria.

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 clear. The description adds value by naming specific return fields (e.g., 'id, type, params'), giving the agent concrete expectations beyond the annotations.

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

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

Two sentences with no fluff: the first delivers purpose and return fields, the second provides usage guidance. Information is front-loaded and every sentence earns its place. Ideal conciseness.

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

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

For a simple tool with one optional boolean parameter and no output schema, the description fully covers purpose, returned fields, and when to use it. No gaps remain for an agent to invoke it correctly.

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

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

Schema coverage is 100%, with the parameter 'include_inactive' clearly described in JSON Schema. The description does not elaborate on this parameter, but since the schema is self-sufficient, a baseline score of 3 is appropriate. No extra meaning is added.

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, specifying the verb 'List' and resource 'subscriptions.' It distinguishes from siblings like 'subscribe,' 'unsubscribe,' and 'watches_active' by focusing on listing, not creating or managing. The mention of returned fields further clarifies scope.

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 using this tool to review subscriptions before adding more or to find an ID to cancel, providing actionable guidance. While it doesn't list alternatives or when not to use, the context is clear and sufficient for basic selection.

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

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

Annotations already declare the tool is read-only, non-destructive, idempotent, and open-world. The description adds only the format hint 'as text page' but does not explain what 'recent' means, default behavior, or return structure. Minimal additional value 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 very short, consisting of one sentence. It is front-loaded but lacks structure and detail. While concise, it omits important context, making it arguably under-specified.

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

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

For a simple tool with one optional parameter and an output schema, the description fails to provide context such as what constitutes 'recent', default limit, or the format of the returned text. The output schema exists but the description does not complement it.

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 0%, and the description does not mention or explain the only parameter 'limit'. It adds no meaning beyond the bare schema, failing to compensate for the lack of parameter documentation.

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

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

The description clearly identifies the resource (mesoscale discussions) and implies it returns a list, with the format hint 'as text page'. While it lacks an explicit verb, it is understandable and distinguishes from weather-related siblings like convective_outlook and storm_reports.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or comparisons with sibling tools like convective_outlook or storm_reports.

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 minimal and neutral. The description adds important behavioral context: rate-limited to 5 per identifier per day, free, and doesn't count against tool-call quota. This fully compensates for the lack of annotation detail.

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

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

The description is well-structured: purpose first, then usage instructions, then constraints. Every sentence adds value. Slightly long but justified by the amount of useful information provided.

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

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

Given the tool's complexity (3 params, nested objects, no output schema), the description covers purpose, usage, parameter details, rate limits, and quota impact. Nothing essential is missing.

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

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

Schema coverage is 100%, baseline 3. The description enhances parameter understanding by explaining the 'type' enum categories in detail and describing the purpose of the 'context' object. It also specifies message length constraints (1-2 sentences, 2000 chars max).

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb ('tell') and resource ('Pipeworx team'), and distinguishes it from sibling tools as the only feedback mechanism.

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 the tool: for bugs, feature requests, data gaps, praise, or other. It also provides a clear negative instruction: 'don't paste the end-user's prompt.' No alternatives exist among siblings, so the guidance is complete.

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, non-destructive. Description adds substantial behavioral context: data source (CF analytics-engine), no PII, caching details (5min-1h), and return content details. No contradiction with annotations.

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

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

Description is well-structured with front-loaded purpose, list of returns, use cases, and data source. Slightly verbose with some repetition (e.g., 'what other agents are calling' and later 'trending'), but overall efficient and easy to scan. Could trim about 20% without losing meaning.

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

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

For a simple tool with one optional parameter, thorough annotations, and no output schema, the description covers all necessary context: what it returns, data source, privacy, caching, and use cases. No gaps for an agent to misunderstand or misuse the tool.

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

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

Schema coverage is 100% with a well-described enum parameter ('window'). The schema description itself provides details on effects of shorter vs longer windows. The tool description only reiterates the options without adding new semantic value beyond the schema, so baseline of 3 is appropriate.

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

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

Clearly states the tool returns trending tools, packs, and call volume on Pipeworx. Uses specific verb ('returns') and resource ('top tools, packs, volume'). Distinguished from siblings like discover_tools (which lists available tools) and ask_pipeworx (which answers questions).

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

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

Explicitly lists three concrete use cases: discovering hot data sources, confirming canonical tools, aligning use case. Does not provide explicit 'when not to use' guidance, but the use cases make the intended context clear. Could mention alternatives like discover_tools for non-trending info.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: internal logic (monotonicity checks, partition_sum, semantic anchor, partition filter, fill check), response structure, and edge cases like skipped_low_similarity. 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 relatively long but every sentence provides value. It is front-loaded with the core action and mode selection. While it packs a lot of detail, it remains organized and readable. Slightly verbose, but appropriate for a complex tool.

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

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

Given the tool's complexity (2 parameters, no output schema), the description is remarkably thorough. It explains input modes, internal logic, output fields (opportunities, partition_check, fill_check), and references related tools. No gaps in context for an agent to understand usage.

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

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

Schema description coverage is 100% (2 parameters fully described). The description adds substantial meaning beyond schema: explains when to use each parameter, provides examples (e.g., 'fed-decision-may-2026'), and details how they affect behavior (single-event vs cross-event). This goes well beyond the baseline of 3.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It specifies the resource (Polymarket markets) and differentiates between three modes (no args, event, topic). This is a specific verb+resource combination with clear sibling differentiation from 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?

The description provides explicit guidance on when to use each mode: 'Call with NO args for a trending_scan... pass event for the strongest per-event partition_check, or topic for a themed cross-event scan.' It also mentions that for custom sizing, use polymarket_fill_risk, offering an alternative. However, it doesn't explicitly exclude scenarios where other sibling tools (e.g., polymarket_edges) would be more appropriate.

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

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing the three model families, edge calculation, response structure, caching behavior, and tradeable-edge knobs. This provides comprehensive behavioral context without contradicting any annotations.

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

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

The description is very long and dense, containing many technical details that could be moved to a separate documentation or details field. While it front-loads the purpose, the sheer volume of information makes it less concise. Every sentence may be informative, but the overall structure could be streamlined.

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 thoroughly explains the response structure (by_segment, fed_candidates, _diagnostics), edge computation, knobs, filters, and caching. Given the tool's complexity (9 parameters, multiple segments, diagnostics), the description is remarkably complete and leaves minimal ambiguity.

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

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

All 9 parameters have descriptions in the input schema, achieving 100% coverage. The tool description adds some additional context for parameter usage (e.g., explaining 'Tradeable-edge filters' and 'min_partition_leg_kelly'), but the bulk of parameter meaning is already in the schema. Baseline of 3 is appropriate.

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

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

The description states it scans Polymarket markets and returns opportunities where data disagrees with market price, clearly indicating the tool's function. However, it does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_edge_tracker, so it falls short of a 5.

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

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

The description includes 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets,' which clearly indicates when to use the tool. It also details adjustable knobs and filters, providing guidance on customization. However, it lacks explicit statements on when not to use it or alternatives, preventing a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds substantial behavioral details: snapshot-based data, TTL bounds, decay computation from daily closes (not intraday), response structure (tracked, expired, snapshot_dates), and interpretation of edge_pp_net signs. 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 detailed and structured with sections (overview, args, response, limits) and uses formatting. It is front-loaded with the core question. While slightly verbose, every sentence adds value and the structure aids readability.

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

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

Despite no output schema, the description fully documents the response: tracked[], expired[], snapshot_dates[], and their fields. It covers limits, TTL, and edge cases (gaps). This is complete for a read-only telemetry 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 descriptions for both parameters. The description adds further meaning: explains lookback default (14), max (30), and window default (1wk), plus context that days limits history depth and window selects snapshot family. This exceeds schema information.

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: tracking edge persistence and decay from daily snapshots, answering 'how long has this edge existed and is it shrinking?' It uses specific verbs ('persistence', 'decay telemetry') and resource ('daily polymarket_edges snapshots'), differentiating it from siblings like polymarket_edges (current edges) and polymarket_arbitrage.

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

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

The description explains the tool's utility ('a fresh wide edge and a 3-week-old wide edge are different trades') and provides limits (TTL, snapshot gaps). However, it does not explicitly state when to avoid this tool or compare to alternatives, though the context implies its niche for historical edge analysis.

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 details beyond the annotations (readOnlyHint, idempotentHint, etc.): it explains walking the order book ladder, returning specific fields like vwap_fill_price, slippage_pp, verdict, and warns about thin_legs and forced directional risk. There is no contradiction with annotations; the tool is indeed read-only and idempotent.

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

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

The description is well-structured with sections (REQUIRES, SINGLE-MARKET, BASKET, USE THIS) and front-loads the purpose. It is lengthy but justified given the tool's complexity; all sentences are informative with no redundancy. A minor deduction for length, but it remains clear.

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

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

Without an output schema, the description fully explains the return values for both modes (e.g., top_of_book, vwap_fill_price, verdict for single-market; theoretical_sum, capture_ratio, profit_usd, per-leg fill detail for basket). It also covers edge cases like forced directional risk and max clean notional. No gaps in context.

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

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

With 100% schema coverage, the description still adds significant value by explaining context-dependent behavior: side default auto for baskets based on partition sum, size_usd interpreted differently for single-market vs basket, and default values. 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 performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth', detailing two modes (single-market and basket) with distinct outputs. It explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by advising 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'.

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

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

The description explicitly states when to use the tool ('before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500') and provides context on why (theoretical overround on thin books is not capturable, partial basket fills convert arb into unhedged directional position). It also specifies required parameters ('REQUIRES one of market or event') and default values.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds extensive behavioral details: two modes, safety fields (compatibility_warning, temporal_alignment, skipped_cross_type/subtype), and response structure. 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 informative but slightly verbose. It is front-loaded with purpose and modes, and every sentence adds value. Could be more concise in explaining safety fields, but overall well-structured.

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

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

Despite no output schema, the description thoroughly explains the response structure, safety fields, and edge cases (compatibility warnings, temporal misalignment). It is complete for a complex tool with 3 optional parameters.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by listing the 10 topic shortcuts and explaining that explicit parameters override the topic-mapped side. This extra context raises the score.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes itself from sibling tools like 'polymarket_arbitrage' by focusing specifically on cross-venue spreads and providing detailed mode and safety field explanations.

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 two modes (topic shortcuts and explicit tickers) and provides guidance on when to use each. It warns that pre-mapped topics often return warnings, implying when to use explicit modes. However, it lacks explicit 'when not to use' guidance beyond the compatibility warning 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: scoping to identifier (anonymous IP, BYO key hash, account ID) and the behavior when omitting the key (list all keys). No contradiction.

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

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

The description is concise (three sentences), front-loaded with the primary action, and every sentence contributes essential information. No unnecessary details.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers its purpose, usage, scoping, and relationship to other tools. No gaps remain.

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

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

Schema coverage is 100% with a description for the single parameter. The description goes further by clarifying that omitting the key lists all saved keys, which adds meaning beyond the schema's basic 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 uses a specific verb ('retrieve'/'list') and resource ('value previously saved via remember'), and distinguishes itself from sibling tools like 'remember' and 'forget' by explicitly pairing with them. The purpose is unambiguous.

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

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

It explains when to use the tool ('to look up context the agent stored earlier'), provides concrete examples (ticker, address, notes), and implies when not to use it ('without re-deriving it from scratch'). It also refers to companion tools for save/delete operations.

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, etc. The description adds value by explaining the mark_read behavior and pollability, without contradicting annotations.

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

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

A single, well-structured paragraph of ~70 words. Every sentence is informative, with the main purpose front-loaded and no redundancy.

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

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

No output schema, but description covers return fields and pagination effects. Lacks error handling details, but sufficient for typical polling use cases.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra meaning by illustrating type filtering with an example and explaining mark_read's effect on subsequent calls.

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

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

The description begins with a clear action verb ('Pull fired events') and specifies the resource ('your subscription feed'). It details return fields and filtering options, distinguishing it from sibling tools like 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?

Provides guidance on polling and mentions an alternative HTTP endpoint. However, it could be more explicit about when to use this tool versus specific 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, idempotentHint, openWorldHint, and no destructive hint. The description adds critical behavioral context: parallel fan-out to three sources, fallback from GDELT to GNews on rate limits/5xx, soft-fail for USPTO due to API sunset, and the return structure (changes grouped by source, total_changes count, pipeworx citation URIs). No contradictions with annotations.

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

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

The description is comprehensive and well-structured, using bullet-like sections within a single paragraph. It is slightly dense due to the amount of context packed in, but every sentence adds value. A minor reorganization could improve readability, but it remains efficient given the tool's complexity.

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

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

Given three parameters, no output schema, and high schema coverage, the description fully covers the purpose, usage, data sources, behavior, and return structure. It explicitly mentions the return format (changes[] grouped by source, total_changes, citation URIs), compensating for the lack of an output schema. The alternative tool is clearly described, making the context complete for an AI agent.

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

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

Schema coverage is 100%, but the description adds significant value: examples for each parameter (ticker 'AAPL', CIK '0000320193'), clarification of 'since' format (ISO date vs relative shorthand like '7d', '30d', '3m', '1y'), and a recommendation for typical monitoring windows. The enum for 'type' is already clear, but the description reinforces the current limitation.

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

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

The description begins with example queries ('What's new with X', etc.) and clearly states it is a change feed for a company over a recent window. It specifies the aggregated sources (SEC EDGAR, GDELT→GNews, USPTO) and distinguishes itself from the sibling tool 'entity_profile', which covers static profiles regardless of time window.

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

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

Explicitly tells when to use this tool versus alternatives: 'Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.' It also provides clear context for typical monitoring ('Use "30d" or "1m" for typical monitoring') and describes fallback behavior between GDELT and GNews.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous sessions. 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 three sentences, each serving a distinct purpose: purpose, usage guidance, persistence details. It is front-loaded with the core action and avoids fluff.

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

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

For a simple 2-parameter write tool with no output schema, the description fully covers purpose, usage, persistence, and sibling pairing (recall, forget). It leaves no significant gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description provides example values for key (e.g., 'subject_property') and clarifies value can be any text, adding modest extra meaning beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later.' It provides specific examples (resolved ticker, target address, user preference) and explicitly distinguishes from sibling tools by mentioning 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 gives clear guidance on when to use: 'Use when you discover something worth carrying forward.' It also notes persistence differences for authenticated vs. anonymous users, but does not explicitly state when not to use or provide alternatives.

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

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

The description discloses internal cascading through multiple lookup endpoints, returns detailed fields including citation URIs, and explains auto-disambiguation. Annotations (readOnlyHint, idempotentHint) already indicate safety, and the description adds behavioral context without contradiction.

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

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

The description is well-structured with a front-loaded overview, followed by detailed type breakdowns. While slightly long, every sentence adds value. Could be more concise, but the structure aids readability.

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 fully covers return values for both entity types, including citation URIs and accepted input formats. It also explains the internal cascading, making the tool's behavior completely understandable without missing key aspects.

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 each parameter has a description. The description adds significant meaning beyond the schema: it explains what each type returns (ticker+CIK for company, RxCUI for drug) and provides examples for values. It could be more structured but adds clear 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 resolves user-spoken names to canonical/official identifiers. It uses specific verbs and resources (e.g., 'resolve entity', 'get ticker/CIK/RxCUI') and distinguishes itself from siblings like 'compare_entities' and 'entity_profile' by being the primary ID lookup tool.

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 'Use FIRST whenever you have a name but need an ID', providing clear context. It also mentions that the tool replaces 2-3 manual lookups, implying efficiency. However, it does not explicitly state when not to use it or compare directly to siblings, but the context is sufficient.

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

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

Annotations already declare read-only, open-world, and idempotent hints. The description adds rich behavioral context: probes each entity with ai_visibility_check, ranks by score, surfaces most/least recognized, and details the return format (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?

The description is three sentences, each with a distinct function: main purpose, usage context, and return value. No fluff, front-loaded with the primary action.

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 sufficiently explains the return format (ranked list with score, confidence, signal density per entity). All 4 parameters are covered in schema descriptions, and the tool's behavior is fully 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% with good descriptions. The tool description adds extra meaning: that the first entity is treated as a 'subject' for narrative, and that models can be omitted for default workers-ai. This goes beyond the schema.

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

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

The description uses a specific verb ('Compare'), names the resource ('AI visibility across multiple entities'), and clearly distinguishes from sibling 'ai_visibility_check' by emphasizing side-by-side comparison and ranking.

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 the use case ('competitive AI-marketing audits') and provides an example question, implying when to use. It hints at the alternative single-entity tool (ai_visibility_check) but lacks an explicit 'do not use for single entities' statement.

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

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

The description adds significant context beyond annotations: partial failures, bundlephobia timing out (5-30s), sources_failed list, and return structure. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and contains valuable information, but it is somewhat dense. Every sentence earns its place, though it could be slightly more streamlined.

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, so description fully explains return values with a detailed list (summary block, advisories, links, alternatives). Also covers edge cases like partial failures and timeout behavior.

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 scoped packages are accepted and version defaults to latest, but these are already in the schema. No additional semantic value beyond the schema.

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

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

The description clearly states it is a composite check for npm packages, combining deps.dev and bundlephobia. It precisely defines the tool's scope and distinguishes it from siblings, which focus on other topics.

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 notes NPM ecosystem only and directs to deps.dev for other ecosystems, providing clear when-to-use 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 indicate readOnly, openWorld, idempotent, and nondestructive hints. The description adds substantial behavioral details: it uses BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, a 200K character cap with truncation flagging, and returns passages with character offsets. 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 concise (a few sentences) yet packed with essential information. It is well-structured: starts with the core function, then usage guidance, technical details, and constraints. Every sentence adds value, though it could be slightly more streamlined by removing redundant mentions of the cap.

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 (semantic search with chunking and similarity), the description is complete. It explains the return format (top-N passages with offsets and scores), technical approach (embeddings, window size), and constraints (200K char cap). No output schema exists, but the description adequately covers what agents can 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 description coverage is 100%, so the parameters are already documented. The description adds value by providing example queries ('supply-chain risk', 'fiscal year 2024 revenue') and clarifying the text parameter's maximum length and truncation behavior, which enhances understanding beyond the schema alone.

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

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

The description clearly states the tool performs semantic search inside a fetched record, specifying the action ('search inside'), the resource ('text'), and the scope ('passages with offsets'). It differentiates itself from siblings like ask_pipeworx_grounded, making its 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 advises when to use the tool: 'Use when the record is too big to cram into the prompt.' It also suggests a complementary tool (ask_pipeworx_grounded) and explains how the two work together, providing clear usage guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, and non-destructive nature. The description adds context: returns raw CSV with specific fields (time, location, magnitude, remarks), which is consistent with annotations. No contradictory behavior mentioned.

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, well-structured sentence that front-loads the action and includes all essential details (resource, date format, filter options, output format). No extraneous words.

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

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

Given the tool has only two optional parameters, an output schema, and comprehensive annotations, the description covers the return format and parameter defaults. It is fully sufficient for an agent to understand and invoke the tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds meaning beyond the schema by explaining the date format (YYMMDD, default today UTC) and the meaning of each kind value (tornado, wind, hail, filtered/combined). This helps an agent understand valid inputs.

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 'Fetch NOAA SPC preliminary storm reports CSV for a given date... filtered by kind', specifying both the verb (fetch) and resource (storm reports). It distinguishes from siblings like convective_outlook by focusing on preliminary reports in CSV format.

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

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

The description implies usage for fetching storm reports by date and kind, but does not explicitly state when to use this tool versus alternatives (e.g., convective_outlook). No exclusion criteria or when-not guidance is 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?

The description goes far beyond annotations, detailing delivery channel behaviors (always-on feed, optional email/sms/webhook), limitations (10 SMS/day, webhook auto-disable after 10 failures), and prerequisites (phone verification). It fully discloses the subscription creation side effect.

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 efficient, front-loading the main purpose and return value. While a single paragraph, it groups related information logically. Minor improvement would be breaking into bullet points for readability.

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 types, parameters, delivery options, and limitations well. However, it lacks details on the response structure beyond the subscription ID, and does not mention error handling or validation failures, which would be helpful for a mutation 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?

With 100% schema coverage, the description still adds rich meaning: it explains each enum value with real examples, details required vs optional fields in nested params objects, and clarifies delivery channel requirements (e.g., webhook signing secret returned once).

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 lists supported types and distinguishes from tools like list_subscriptions, unsubscribe, and recent_alerts.

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

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

The description provides explicit usage guidance: it requires a Pipeworx OAuth account and notes that anonymous/BYO cannot persist subscriptions. It also gives examples for each subscription type, helping users understand when to use each.

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 safe, non-destructive, idempotent behavior. The description adds valuable behavioral context: it returns live examples, covers multiple categories, and acts as an onboarding tool. 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?

Description is front-loaded with common queries and efficiently conveys purpose, usage, and output. Every sentence contributes, though slightly verbose with alternative phrasings.

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

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

Given the tool's simplicity (1 optional param, no output schema) and rich annotations, the description fully covers what the tool does, when to use it, and what it returns. Complete for an onboarding tool.

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

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

Schema coverage is 100% for the single optional parameter. Description enriches it by listing valid values (finance, pharma, etc.) and explaining how omission yields a cross-category spread, providing meaning beyond schema.

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

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

Description uses specific verbs ('returns category-bucketed example questions') and clearly identifies the resource. It distinguishes from siblings like discover_tools by positioning itself as the onboarding entry point and explicitly states when to call 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?

Explicit guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. It also explains when to pass topic vs omit for full spread, providing 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?

Adds critical behavioral details beyond annotations: ownership enforcement, deactivation (not deletion), and historical availability. 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 focused sentences, each adding value; front-loaded with the core action.

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

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

Complete coverage for a simple tool: ownership, side effects, and relation to recent_alerts.

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 does not add extra meaning to the 'id' parameter 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?

Description clearly states verb 'Cancel' and resource 'subscription by id', distinguishing it 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?

Provides clear context on ownership enforcement and the deactivation behavior, but does not explicitly state when not to use or alternative tools for other actions.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive behavior. The description adds detail on the two verification paths (SEC EDGAR for financial claims, grounded pipeline for others), the verdict types returned, and evidence citation, enhancing transparency without contradiction.

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

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

The description is somewhat lengthy but well-structured, with purpose stated upfront followed by operational details. Every sentence contributes useful information, though minor trimming could improve conciseness.

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

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

Despite lacking an output schema, the description fully explains return values (verdict types, actual value, citation, reasoning). It covers both claim types and the two verification paths, making the tool's behavior completely understandable.

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 descriptions are clear. The description adds value by explaining tolerance_pct usage with examples like 'set 1–2 for hallucination detection', going beyond the schema to clarify semantic context.

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

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

The description clearly states the tool's purpose as 'natural-language claim verification against authoritative sources' and provides multiple example phrases. It distinguishes itself from sibling tools by specifying a unique fact-checking function.

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 differentiates between company-financial claims and other claims, and notes that it replaces multiple sequential calls, providing clear guidance on when to 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 already declare the tool as read-only, idempotent, and non-destructive. The description adds that output is a 'summary text' and that it concerns 'currently-active' watches, implying time-sensitivity. This adds value beyond annotations but is minimal.

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

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

The description is extremely concise (4 words) and front-loaded. However, it may be too brief, lacking context that clarifies 'watches' as weather-related. It earns its place but could benefit from slight expansion.

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 (no params, output schema exists), the description is mostly complete. It states the output is a summary text of active watches, but does not explicitly link to weather context. An AI agent might infer from sibling names, but explicit mention would improve completeness.

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

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

No parameters exist, and schema coverage is 100% by default. Baseline score of 3 is appropriate; the description adds nothing about parameters, which is acceptable.

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 'Currently-active watches summary text' clearly indicates the tool returns a summary of active watches. The verb 'summary' and resource 'watches' are specific. However, it does not explicitly differentiate from sibling tools like convective_outlook or storm_reports, though context implies these are different weather products.

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 alternatives. Given the list of sibling tools with overlapping weather domains, explicit usage context would help but is absent.

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