Open Meteo

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

The description adds significant behavioral context beyond annotations: it lists returned pollutants and pollen types, mentions a 5-day forecast horizon, and notes that it is free and keyless. All annotations (readOnlyHint, idempotentHint, etc.) are consistent and complemented.

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 sentence with embedded examples, which is reasonably concise but could be broken into clearer segments. It front-loads common queries, making it easy to grasp quickly.

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 output schema exists (though not shown), the description fully covers what the tool returns, including pollutants, pollen, and AQI types, as well as the data range. It leaves no major gaps for an AI agent to invoke the tool correctly.

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

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

While latitude and longitude have no schema description, the description covers their purpose by stating 'any lat/lng' and provides examples. It also explains the 'hourly' parameter's possible values (PM2.5, PM10, etc.) and the 'forecast_days' range. This compensates for the 50% 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 it provides global air quality and pollen forecast data at any lat/lng, with specific examples like 'is the air safe to breathe in [location]'. It distinguishes itself from sibling tools like 'forecast' by focusing exclusively on air quality parameters.

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 concrete example queries that implicitly guide when to use this tool (e.g., for pollution levels, smoke, pollen). It does not explicitly mention when not to use it or compare with alternatives, but the specificity makes the intended use clear.

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

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

The description goes beyond annotations by detailing behavior: default model, cost implications of using _apiKey ('you pay Anthropic directly'), and the return structure shape. It aligns with annotations (readOnly, idempotent) and adds valuable context about payment and probe mechanics.

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 with zero fluff. The core action 'Probe one or more LLMs...' is first, followed by specific details and use cases. Every sentence serves a purpose, making it efficient and well-structured.

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

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

With no output schema, the description provides a solid overview of return values (score, confidence, signals, raw_response, combined view). It lacks detail on signal interpretation or algorithm, but for a 4-parameter tool with good annotations and clear use cases, it is sufficiently complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema: it clarifies that _apiKey is only needed with anthropic model, and that context helps disambiguate. This extra context justifies a score above baseline.

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

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

The description clearly states the tool's purpose: probing LLMs for visibility of an entity and scoring it 0-100 per model. It specifies the verb 'probe' and resource 'LLMs', and the mention of default model and optional Anthropic helps distinguish from similar tools like scan_competitor_ai_presence.

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 lists explicit use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring', which guide when to use. However, it does not mention when to avoid this tool in favor of alternatives like scan_competitor_ai_presence, missing a clear exclusionary guideline.

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 state readOnly, openWorld, idempotent, non-destructive. Description adds meaningful behavior: routes to a huge tool ecosystem, fills arguments, returns structured answer with citation URIs, and notes 'one fast call' and 'works on every tier'. This goes beyond the annotation basics without contradicting them.

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

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

Long but well-structured: opens with a strong directive, then domain examples, trigger phrases, sample queries, and escalation hierarchy. Every sentence earns its place, though slightly verbose. Front-loaded with the most important preference guidance.

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, but description explicitly states return format (structured answer with citations). Covers when to use, when not to use, alternatives, examples, and even mentions free tier compatibility. Comprehensive for a query tool of this complexity.

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

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

Input schema already covers all 6 parameters with high coverage; all are aliases for 'question'. The description adds user-facing examples and contextual triggers but no additional parameter-level semantics. Schema does the heavy lifting, so baseline 3 is appropriate.

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

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

Clear verb+resource: 'PREFER OVER WEB SEARCH' positions it as a question-answering tool that routes to 5,462 tools. It explicitly differentiates from siblings by naming escalation paths to ask_pipeworx_grounded and deep_research, and from web search by preference.

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 whenever the user asks...' gives trigger phrases, 'START HERE for most questions' establishes default role, and 'Step up only when needed' names specific alternatives with conditions (hallucination-resistant, broad/multi-part). Also mentions when web search might be considered but this should be preferred.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond annotations: it's a live experimental router with candidate improvements, currently matches ask_pipeworx exactly, and 'falls back to nothing — this IS a full working router', clarifying it is not a stub. 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 efficiently front-loaded with 'Beta version of ask_pipeworx' and conveys essential information without fluff. It is slightly dense but every sentence earns its place, covering purpose, current state, usage, and experimental nature.

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 should explain return values, but it only says 'same response shape' without specifying what that shape is. It covers purpose, usage, and current state well, but leaves the response format ambiguous. For a beta tool, this is a notable gap.

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

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

The schema covers 100% of parameters, all documented as aliases for 'question'. The description adds no additional parameter detail, but the schema already fully describes the required question field and its aliases. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states this is a beta version of ask_pipeworx, an identical universal router with the same 5,462 tools, arguments, and response shape. It distinguishes itself by being the experimental edge with candidate routing improvements, and explicitly references the stable ask_pipeworx sibling.

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

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

Explicitly says to 'use it exactly like ask_pipeworx when you want the newest routing' and mentions results are compared against the stable router, which implies when not to use it (when you want stable routing). However, it doesn't provide an explicit when-not-to-use exclusion, so it falls short of a perfect score.

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

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

Annotations already mark the tool as readOnly and idempotent; the description goes beyond by detailing the exact return payload ({answer, evidence, confidence, source, fetched_at, refusal_reason}) and enumerating specific refusal reasons (not_in_source, no_tool_match, etc.). It also discloses the extra LLM call cost and the constraint of using only tool results.

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

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

The description is dense but every sentence serves a purpose: defines the mode, explains the mechanism, details the return format, lists failure modes, states when to use, and gives a cost comparison. It is front-loaded with the core purpose and structured logically, earning its length without redundancy.

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

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

With no output schema, the description must explain return values and failure modes — it does both comprehensively. It also covers key context like the underlying routing, the grounding constraint, and cost implications, making it complete for an agent to decide and invoke correctly.

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

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

The schema description coverage is 100% — all six parameters are aliases for the same natural-language question, each with a description. The tool description adds no additional meaning to the parameter itself, only mentions that the tool 'fills arguments' internally, which is about routing behavior, not about the 'question' parameter. Baseline 3 is appropriate since schema already fully documents the parameter.

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

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

The description opens with 'Hallucination-resistant answer mode for high-stakes reads' — a specific verb and resource that directly states what the tool does. It distinguishes itself from the sibling ask_pipeworx by emphasizing extraction grounded in tool results, making the purpose unambiguous.

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

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

Explicitly states when to use ('whenever an answer will be quoted, cited, or acted on') and when to avoid ('prefer ask_pipeworx for casual lookups'), even naming the alternative sibling. Also discloses the cost tradeoff ('one extra LLM call'), giving clear decision 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description extensively discloses behaviors beyond annotations: low-confidence short-circuit, closed market handling, wide-spread tradeability, cancellation rules, news fallback, resolver contract, and parent extractor. 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 densely packed with essential details for a complex tool. It could benefit from more structure (e.g., sections), but every sentence adds value, and the front-loaded usage guidance helps agents quickly understand purpose.

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

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

Despite no output schema, the description thoroughly explains response shapes (result.market, result.analysis, result.evidence), resolver contract (match confidence, alternatives, suggestions), parent event extractor, news fields, and safety mechanisms. It covers all necessary context for complex tool 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%. The description adds meaningful context: market parameter format (slug, URL, or question text), depth enum default and behavior, include_raw explanation of when to use true vs false. This adds value beyond schema.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, resolving the market, classifying, fanning out to data packs, and returning evidence and comparison. It distinguishes from sibling tools like polymarket_edges or polymarket_arbitrage which focus on specific aspects.

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

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

The description explicitly lists use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z') and provides classifier examples. It doesn't explicitly state when not to use or contrast with siblings, but the context is clear.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds specifics: pulls SEC 10-K data for companies, FAERS data for drugs, handles off-calendar fiscal years, sorts by metric, returns paired data with URIs. No contradiction with annotations.

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

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

Seven sentences, each with distinct value: query examples, usage preference, data details, sorting, output format. Front-loaded with common patterns, no redundancy.

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

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

For a 2-parameter tool with no output schema, description covers purpose, usage preference, data source, sorting, and return format. Complements annotations and sibling context well.

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

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

Schema coverage is 100%, description enriches parameters: 'type' maps to data sources (SEC vs FAERS) and specific metrics, 'values' specifies tickers/CIKs for companies, drug names. Adds meaning beyond schema structure.

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 'side-by-side comparison of 2–5 companies or drugs', specifying verb (compare), resource (entities), and scope (comparison). Differentiates from siblings like entity_profile (single entity).

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear context for use. Examples of query patterns provided, but no explicit exclusions for when not to use.

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

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

Despite strong annotations (readOnly, openWorld, idempotent, not destructive), the description adds substantial behavioral context: account requirements, parallel tool routing, findings packet structure with gaps[], never-invented guarantee, second-hop recovery, contradictions[], semantic excerpting, and latency expectations. 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 information-dense; every sentence conveys a distinct point. It is front-loaded with the critical account requirement and alternatives. Slight deduction for being a wall of text, but the complexity justifies its length.

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

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

For a complex tool with no output schema, the description covers return format (findings packet), citation URIs, gaps[], contradictions[], timing, and integration with other tools. It addresses the full user journey from prerequisites to result interpretation, making it nearly complete.

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

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

Schema coverage is 100% and the schema already explains both parameters well. The description adds value by elaborating on the depth enum (quick/standard/thorough differences) and explaining what kind of questions are suitable ('Broad/multi-part is fine'), exceeding the baseline.

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

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

The description explicitly names the tool's function: 'Grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources' with decomposition and parallel routing. It clearly distinguishes from sibling ask_pipeworx and open-web search, using specific verbs and resource 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?

Provides explicit when-to-use ('best for broad/multi-part questions over structured data') and when-not-to-use ('For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'). It names alternative tools and even explains the account limitations, making selection unambiguous.

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

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

The description adds significant behavioral info beyond annotations: it reveals that results include full input schemas with curated examples, and that each result is ready to call directly. Annotations (readOnlyHint, idempotentHint) are consistent with a discovery 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?

Two sentences, no redundancy, front-loaded with critical info. Every sentence adds value: the first covers purpose and examples, the second covers return format and usage guidance. No word wasted.

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

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

Given no output schema, the description adequately explains the return format ('top-N most relevant tools with names, descriptions, and full input schemas'). It also addresses the discovery context and the fact that results are ready to call. Completeness is high.

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

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

Schema description coverage is 100%, so the schema already fully documents all 6 parameters. The description adds no new semantic information beyond the schema; it merely restates that query accepts aliases. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists specific domains (SEC filings, financials, etc.) and differentiates from siblings by advising to call this first when exploring the option set. The title and name are reinforced with specific verb+resource.

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: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It provides clear context but does not explicitly state when not to use or mention alternatives, though the sibling context implies it.

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

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

Annotations declare read-only, open-world, idempotent, non-destructive. Description adds context: fans across multiple sources, USPTO sunset mentioned, soft-fail behavior, and fallback mechanisms. 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 a single dense paragraph but front-loaded with examples and clear use cases. Every sentence adds value; no fluff though slightly verbose for the amount of information.

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

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

Tool has 2 params, no output schema, and moderate complexity (multi-source). Description lists all return fields (cik, filings, fundamentals, patents, news, LEI) and includes caveats (USPTO sunset, soft-fail). Sufficient for agent to understand outputs.

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 type and value. Description goes further by providing examples ('AAPL', '0000320193') and explicitly stating names are not supported, adding clarity 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?

Description uses specific verb 'profile' with resource 'US public company' and lists concrete outputs. It distinguishes from single-pack lookups by stating 'ALWAYS PREFER over chaining single-pack...' and provides example queries.

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

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

Explicitly states when to use ('holistic view' vs. chaining) and when not (names not supported, instructs to use resolve_entity first). Provides acceptable input formats (ticker or zero-padded CIK).

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

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

The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by specifying that the output is daily discharge in m³/s for any river-bearing location, and that the forecast extends up to 30 days. It does not contradict annotations. Lacks details on data freshness or model version, but 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 moderately concise but starts with multiple example queries framed as questions, which adds redundancy. The core explanation (2 sentences) is effective, but the example list could be shortened. It front-loads the purpose well, but some content feels repetitive.

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

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

Given that an output schema exists (so return values are documented elsewhere), the description covers the main purpose and usage. However, it lacks explanation of behavior for non-river locations, parameter defaults, and error conditions. The low parameter schema coverage and absence of parameter details in the description reduce 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?

Schema coverage is only 25% (only the 'daily' parameter has a description, which is vague: 'Default river_discharge'). The tool description mentions latitude, longitude, and forecast_days implicitly but does not explicitly clarify their meaning, types, or constraints. With 4 parameters and a focused description, more parameter-level detail would aid correct usage.

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

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

The description clearly identifies the tool as a daily river discharge forecast, specifying the data source (GloFAS), unit (m³/s), and time horizon (30 days). It includes example queries that clarify the tool's scope, but does not explicitly distinguish it from the sibling tool 'forecast', which might also be weather-related.

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 three use cases: flood risk assessment, agriculture planning, and hydrology research. This provides clear guidance on when to use the tool. However, it does not mention when not to use it or suggest alternative tools for different scenarios.

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

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint. The description adds value by revealing the data sources (Open-Meteo/ECMWF + national weather services), the free and keyless nature, and the default return variables (temperature, precipitation, wind, humidity, cloud cover, weather codes). 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 front-loaded with example queries, which is effective. It conveys necessary information in a compact form, though slightly dense. Every sentence adds value: examples, capability, customization, source, and pairing advice.

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 (9 parameters, output schema exists), the description covers all essential aspects: purpose, usage pattern, default behavior, customization options, and external dependencies. It pairs well with the output schema to provide a complete 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 high (78%). The description adds meaning by explaining that hourly/daily args allow custom variable selection, and implies that daily and hourly can be 'comma-separated' variables. It also highlights the required latitude/longitude. This enriches the 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 it provides global weather forecasts up to 16 days ahead with specific example queries (e.g., 'What's the weather in [city]'). It distinguishes from siblings like geocode (which is the prerequisite to convert place names) and other weather-related tools like air_quality or marine.

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

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

The description advises pairing with geocode to convert city names to lat/lng, which is a clear usage guideline. It mentions free and keyless availability but does not explicitly state when not to use this tool versus alternatives like air_quality or marine, though the context implies it for general weather forecasting.

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 destructiveHint=true and idempotentHint=true. The description adds behavioral context about deleting sensitive data and clearing stale context, which complements the annotations. No contradiction found.

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

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

The description is two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every sentence serves a clear purpose.

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

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

For a simple tool with one parameter and no output schema, the description fully covers the tool's purpose, when to use it, and its relationship to sibling 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 single parameter 'key' described as 'Memory key to delete'. The description does not add further parameter details 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 explicitly states the action 'Delete a previously stored memory by key', which clearly identifies the verb (delete) and resource (memory). It also distinguishes itself from siblings like 'remember' and 'recall' by implication.

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

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

The description provides explicit use cases ('when context is stale, the task is done, or you want to clear sensitive data') and suggests pairing with related tools. It lacks explicit when-not-to-use guidance, but the context is clear enough for most scenarios.

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, and non-destructive. The description adds behavioral details: fetches the page, extracts title/description/key links, emits standard markdown. 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, front-loaded with the main purpose, and uses specific examples. Every sentence adds value with no fluff.

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

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

Given 2 parameters, no output schema, and rich annotations, the description fully covers what the tool does, how it works, and when to use it. No gaps.

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

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

Schema has 100% coverage for both parameters. The description mentions URL and max links but does not add significant meaning beyond the schema descriptions. 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 it generates a production-ready llms.txt file for any URL, specifying the purpose and output format. It distinguishes itself from sibling tools by focusing on llms.txt generation for AI crawlers.

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

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

The description provides explicit use cases: indexing a client's site, drafting for own project, or auditing a competitor. It lacks explicit when-not-to-use or alternatives, but the context signals make it clear.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that the tool is free and keyless (no authentication needed), and returns up to 100 matches ranked by population. This provides useful behavioral context beyond annotations without contradiction.

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

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

The description is two sentences with no wasted words. The first sentence provides examples and the core action; the second adds constraints and usage guidance. It is front-loaded and efficient.

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

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

Given the tool has 3 parameters with full schema coverage and an output schema, the description is complete. It explains purpose, usage, output behavior (ranking by population), and integration with sibling 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 description coverage is 100%, so baseline is 3. The description mentions the 'name' parameter implicitly via examples but does not add detail for 'count' or 'language'. The description adds minimal semantic value beyond the schema, so a 3 is appropriate.

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

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

The description clearly states the tool resolves place names to lat/lng coordinates for use with other Open-Meteo tools. It provides example queries and explicitly distinguishes from sibling tools like forecast and historical. The verb 'resolve' and resource 'place name' are specific and unambiguous.

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

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

The description explicitly says to use this tool before forecast/historical/air_quality/marine/flood when only a place name is available, implying when not to use. It also notes it's free, keyless, and multilingual, giving context for when it's appropriate.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and no destruction. The description adds value by specifying the data source (ERA5), output types (hourly/daily, variables like temperature, precipitation), and global coverage. It does not contradict annotations and provides context beyond what annotations offer.

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

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

The description is two sentences with no fluff. The first sentence starts with example queries and key facts (ERA5, 1940-present, global). The second sentence covers return data and use cases. Every phrase earns its place.

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

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

Given the complexity (ERA5 reanalysis, multiple variables, global), the description covers the time range, location, data types, and use cases. An output schema exists (mentioned), so return structure is not needed. Missing details on parameter syntax for daily/hourly variables (e.g., what values are accepted) reduce completeness slightly.

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 only 29% schema description coverage, the description should detail parameters. It mentions latitude/longitude as 'any global lat/lng' and date range, but does not explain the 'daily' and 'hourly' parameters, which appear in examples but lack schema descriptions. The description says 'returns hourly or daily...' but does not tell how to specify variables. This gap reduces usefulness for the agent.

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 historical weather data using ERA5 reanalysis, covering 1940-present at any global lat/lng. Example queries ('What was the weather on [date]') and the mention of specific data types (temperature, precipitation, etc.) make the purpose unambiguous. It distinguishes from siblings like 'forecast' by emphasizing past data.

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

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

The description explicitly says 'Use for climate analysis, retrospective event weather, or training data.' This gives clear use cases. It implies it is for past data by stating the time range (1940-present). It does not explicitly say when not to use it (e.g., for forecasts), but the context is clear given sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds that it returns specific fields and defaults to active subscriptions, which is consistent.

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

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

Two sentences with no waste: first states purpose and return fields, second gives usage guidance.

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

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

Covers purpose, return fields, and usage context. No output schema, but return fields are specified. Adequate for a simple list 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 covers the parameter fully; description doesn't add extra semantics beyond default behavior implied by 'active subscriptions'.

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

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

Clearly states it lists the caller's active subscriptions, specifying return fields. Distinct from sibling tools like subscribe and unsubscribe.

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

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

Explicitly advises use before adding more subscriptions or to find an id to cancel, providing clear context for when to invoke.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint, which inform the agent about safety and idempotency. The description adds that it is 'free, keyless' and global, but does not disclose rate limits or data freshness. It does not contradict annotations.

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

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

The description is a single paragraph but is well-structured: it starts with example queries, then the core functionality, then use cases. It is concise and front-loaded with key information, though it could be more structured with bullet points.

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

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

Given the presence of an output schema, the description does not need to cover return values. It covers the tool's purpose, use cases, and parameters moderately. However, it lacks details on data source, update frequency, and does not fully describe all parameters. It is adequate but not comprehensive.

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

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

Schema coverage is only 25%, with only the 'hourly' parameter having a description. The description mentions the output variables (wave height, period, etc.) but does not explain the parameters beyond what the schema provides. For 4 parameters (2 required), the description should add more context but fails to do so.

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

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

The description clearly states the tool provides marine weather forecasts (wave height, period, direction, etc.) for any ocean location. It gives explicit example queries and use cases, and it clearly distinguishes itself from any sibling tools which are unrelated.

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 lists appropriate use cases: surf reports, sailing prep, fishing conditions, coastal planning. It does not explicitly state when not to use or provide alternatives, but the tool's unique domain makes it clear. The sibling list contains no similar marine tool, so guidance 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 provide no safety hints (readOnlyHint=false, etc.), so the description must carry the burden. It discloses rate limiting ('Rate-limited to 5 per identifier per day'), quota exemption ('doesn't count against your tool-call quota'), and human processing cadence ('team reads digests daily and signal directly affects roadmap'). These behavioral details go well beyond structured metadata.

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 appropriately sized and every sentence earns its place: purpose, triggers, exclusions, content guidance, and constraints. It is well-structured and front-loaded with the core action, then layers practical guidance without redundancy or filler.

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

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

For a tool with 3 parameters, no output schema, and a nested context object, the description covers the full envelope: what to report, when not to report, how to phrase feedback, what happens to the report (daily digest, roadmap), and operational limits. Nothing critical is left unstated.

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 usage nuance that enriches parameter understanding: instructing to describe issues 'in terms of Pipeworx tools/packs — don't paste the end-user's prompt' clarifies how to fill the message and context fields. It also clarifies which tools qualify as Pipeworx tools ('the ones this connection lists'), directly aiding the 'context' object.

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

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

The description opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist' – a specific verb+resource (send feedback) that clearly distinguishes this from sibling tools, which are data/analysis tools. It explicitly states the tool's function and scope, including the kinds of feedback (bug, feature, data_gap, praise).

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 conditional triggers are provided: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also gives a clear exclusion: 'ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server... file it with that server instead.' This is thorough, actionable guidance with alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc., reducing the burden on description. The description adds valuable context: derived from CF analytics-engine, no PII, and caching behavior (5min-1h). This goes beyond what annotations provide, enhancing transparency.

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?

Five sentences covering purpose, use cases, data derivation, and caching. Information is front-loaded with a clear statement of what the tool does, followed by structured utility. No extraneous or redundant text.

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

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

Given the tool's simplicity (1 optional param, no output schema, rich annotations), the description covers all necessary context: what it returns, how it's derived, usage scenarios, and caching. No gaps identified.

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

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

Schema description coverage is 100% and the schema already explains the window parameter with enum choices and usage hints. The main description does not add further parameter details, so it meets the baseline expectation without adding extra meaning.

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

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

Description clearly states the tool returns 'top tools, top packs, and total call volume' for trending activity on Pipeworx. The verb 'trending' matches the name, and the resource is well-defined (aggregated call data). It distinguishes itself from potential siblings like 'discover_tools' by focusing on what other AI agents are using.

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?

Three explicit use cases are provided: discovering hot data sources, confirming canonical tool choice, and checking alignment with majority usage. While no explicit alternatives or when-not scenarios are given, the use cases are specific and actionable, offering clear guidance on when to use the tool.

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

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

Annotations already indicate readOnly, openWorld, idempotent. Description adds detailed behavioral context: semantic anchor (Jaccard similarity), partition filter, fill check against CLOB depth, and response structure. 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?

Long but well-organized into sections. Every sentence adds value. Could be slightly more concise, but the complexity warrants the length.

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

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

Thoroughly explains response structure (opportunities[], partition_check, fill_check) despite no output schema. References sibling tool for custom sizing. Complete for a complex arbitrage tool.

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

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

Schema coverage is 100%, but description adds further meaning: explains event slug format, examples, that full URLs work, and topic seed question examples. Also describes the behavior when each parameter is used.

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

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

Clearly states it finds arbitrage opportunities via monotonicity violations and partition-sum checks. Distinguishes three modes (trending_scan, event, topic) and explains each. Differentiates from sibling tools like polymarket_edges.

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

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

Explicitly says when to use each mode: no args for trending_scan, event for per-event checks, topic for cross-event scans. Recommends event mode for specific markets. Explains when not to trade (realizable_edge_pp <= 0). Provides clear guidance.

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

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

The description extensively discloses behavioral traits beyond annotations: caching behavior (1h at KV level), exclusion of Fed bets due to unreliable signal, diagnostic output for empty segments, and details on edge calculation and warnings. Annotations confirm read-only and idempotent nature; no contradictions.

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

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

The description is dense but well-structured, front-loading the purpose and then detailing model families, output fields, and knobs. While somewhat verbose, every sentence adds useful information for an AI agent selecting or invoking the tool. A slightly more concise version could achieve 5.

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 (9 parameters, no output schema), the description is remarkably complete. It explains the output structure (by_segment, fed_candidates, _diagnostics) and every field carried by opportunities, enabling an agent to understand what to expect. 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%, so baseline is 3. The description adds value by explaining how parameters interact (e.g., min_partition_leg_kelly applies to per-leg Kelly, not parent-level) and the rationale behind defaults (e.g., slippage_pp mentions Polymarket's zero fees but thin depth). This extra context justifies a score of 4.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price, with the explicit use case of 'what should I bet on today'. It distinguishes itself from sibling tools (e.g., polymarket_arbitrage) by detailing its unique model families and methodology.

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

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

The description provides clear context for when to use the tool (discovering betting opportunities without paging through markets) and includes filtering knobs and diagnostics. However, it does not explicitly state when not to use it or compare with alternative tools, though the sibling list implies alternatives exist.

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 fully explains the source (daily snapshots), data fields (tracked, expired, snapshot_dates), computation details (trend, decay_pp_per_day), and limitations (not intraday). Annotations already indicate read-only and idempotent, and the description adds 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 well-organized: starts with the core question, then explains response fields, and ends with limits. Every sentence provides unique value without redundancy.

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

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

Despite no output schema, the description fully specifies the response structure (tracked, expired, snapshot_dates with their fields) and covers edge cases (gaps, TTL, computation method). Complete for a complex analytical 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?

Both parameters have 100% schema coverage with descriptions. The description adds defaults (days=14, window='1wk'), constraints (clamp 2-30 for days), and explains the meaning of window in context of snapshot families.

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

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

The description clearly states it provides edge persistence and decay telemetry, answering 'how long has this edge existed and is it shrinking?'. It distinguishes from sibling tools like polymarket_edges by focusing on historical trends rather than current snapshots.

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 using this tool to differentiate between fresh and old edges, and mentions limits like 60-day TTL and snapshot frequency. However, it does not explicitly state when not to use it or directly contrast with sibling tools like polymarket_edges.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint false, and description adds behavioral details: walks the ladder, returns fill details and verdict (clean|degraded|cannot_fill), warns about forced directional risk. 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 verbose but front-loaded with key information. Every sentence adds value, though slight redundancy in explaining modes. Could be slightly trimmed without losing clarity.

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

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

No output schema but description lists all return fields for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp, verdict, etc.). Covers complexity of two modes and four parameters fully, with no gaps.

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

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

Schema coverage is 100% but description goes beyond: explains default size_usd interpretation for buys vs sells, basket mode interpretation as settlement notional, auto detection of side from partition sum. Adds rich meaning beyond schema types.

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

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

Description clearly states it performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. This is a specific verb+resource that differentiates from siblings like polymarket_arbitrage and polymarket_edges.

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

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

Explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains the rationale (theoretical overround not capturable, partial fills cause directional risk). Provides clear context and exclusions.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description goes far beyond by detailing compatibility warnings, temporal alignment, skipped cross types, and the meaning of matched_pairs counts. This additional context fully discloses the tool's behavior and limitations.

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

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

The description is detailed but well-organized with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). While slightly lengthy, every sentence provides necessary context. It front-loads the core purpose and mode selection, making it efficient for an AI agent to parse.

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

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

Given there is no output schema, the description completely covers the response structure and edge cases (compatibility warnings, temporal alignment, skipped comparisons). It addresses the complexity of cross-venue spreads and the fact that most pre-mapped topics are not currently tradeable, giving a realistic and thorough picture.

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 within schema are clear. The tool description adds value by explaining the topic parameter's exact list and how explicit parameters override topic-mapped sides. It also describes response fields like top_spreads_pp, compatibility_warning, and temporal_alignment, enriching the agent's understanding beyond the input schema.

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

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

The description clearly states the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from sibling tools like polymarket_arbitrage by specifying it's a cross-venue comparison. The two modes (topic shortcuts and explicit parameters) are explicitly described, making the purpose unambiguous.

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

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

The description provides clear guidance on when to use each mode (topic for pre-mapped shortcuts, explicit for custom pairings). It warns that most pre-mapped topics return compatibility warnings, setting expectations. However, it does not explicitly contrast with alternative tools like polymarket_arbitrage or polymarket_edges, leaving some decision-making to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavior beyond annotations: scoping to identifier, listing all keys when omitted, and pairing with remember/forget. No contradiction.

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

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

Three sentences, each earning its place: action, usage context, and pairing. Front-loaded with the primary purpose. No wasted words.

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

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

For a simple retrieval tool with one parameter and no output schema, the description fully explains behavior, scope, and complementary tools. Annotations cover safety, so no gaps.

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

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

Schema coverage is 100% and the description restates what the schema says ('omit to list all keys'). It adds no new parameter semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description states 'Retrieve a value previously saved via remember, or list all saved keys' with specific verb+resource. It clearly distinguishes from sibling tools like remember and forget, and gives concrete usage examples (ticker, address, notes).

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 says 'Use to look up context the agent stored earlier... without re-deriving it from scratch' and mentions scoping. It implicitly contrasts with other tools that fetch external data, but does not explicitly exclude inappropriate use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; the description adds behavior like mark_read affecting future calls and the format of returned events, 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?

Four sentences with no fluff. The core purpose is front-loaded, each sentence adds value, and the description is well-structured for quick parsing.

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

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

Without an output schema, the description adequately covers return content (source, citation_uri, payload) and filtering. The mention of mark_read and alternative access completes the context for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context by explaining the filter parameters (type, since) and mark_read effect, going beyond the schema's generic descriptions.

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

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

The description clearly states it pulls fired events from a subscription feed and details what each alert carries (source, citation_uri, payload). It distinguishes itself from siblings like subscribe/unsubscribe by focusing on retrieval of existing 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?

It provides usage context by mentioning polling works fine and offers an alternative (GET endpoint for scripts/dashboards). However, it does not explicitly compare against other reading tools or state when not to use this tool.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: parallel fan-out across sources, fallback logic, 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 a single, well-structured paragraph. It front-loads query examples, then defines the tool's scope and behavior. Every sentence adds necessary context without repetition.

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

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

Despite no output schema, the description explains the return format (changes[] grouped by source, total_changes, citation URIs). Parameters are fully documented, and the tool's complexity is adequately addressed.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the since format with examples (ISO date, relative shorthand) and suggesting typical monitoring windows. It also clarifies the value parameter accepts ticker or CIK.

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

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

The description clearly identifies the tool as a change feed for a company, querying multiple sources (SEC EDGAR, GDELT/GNews, USPTO). It explicitly distinguishes from the sibling tool entity_profile, which handles static profiles.

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 query examples and states when to use entity_profile instead. It also explains fallback behavior (GDELT→GNews) and soft-fail conditions (USPTO).

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

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

Discloses scoping by identifier and retention policy. IdempotentHint=true is annotated; description aligns by describing overwrite-on-same-key behavior implicitly. Adds 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?

Efficient and front-loaded. Every sentence adds value, no redundancy. Clear structure: purpose, usage, specifics, partner tools.

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 for a key-value store tool. Schema fully covers params, annotations present. Description adds scope and retention. Slight gap on size limits, but not critical.

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

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

Schema coverage is 100%, and the description restates the parameter meanings without adding significant new detail beyond the schema examples.

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 saves data for reuse later. Specifies key-value storage, scoped by identifier. Distinguishes from siblings by mentioning pairing with 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?

Provides clear usage scenarios with examples (resolved ticker, user preference). Notes persistence duration for authenticated vs anonymous users. Lacks explicit when-not-to-use but sufficient for 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 provide readOnly/idempotent/non-destructive signals. The description adds valuable behavioral context: internal cascading through multiple endpoints, replacing 2-3 manual lookups, and detailed return structures with citation URIs. This goes well beyond the annotations.

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

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

The description is moderately long but every section earns its place: example queries, supported types, usage directive, and efficiency context. The 'SUPPORTED TYPES' structure aids readability, though the example list could be slightly condensed.

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

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

With no output schema, the description must explain returns. It fully does so for both entity types, including data sources, citation URIs, and accepted input formats. It also covers the cascading lookup behavior, making it complete for an agent to know 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?

The schema covers 100% of parameters with detailed descriptions. The description adds minimal new parameter semantics—mainly the 'auto-disambiguated' note and citation URIs, which are more about return behavior than parameter meaning. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool's purpose: resolving user-spoken names to canonical identifiers, with concrete example queries. It distinguishes from siblings by noting that other tools require these identifiers, making it the primary 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?

Explicit guidance is given: 'Use FIRST whenever you have a name but need an ID.' This tells the agent when to invoke the tool. However, it does not explicitly mention alternative tools (e.g., entity_profile) for exclusion, so it lacks a full when-not-to-use 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?

Annotations already declare readOnly, idempotent, openWorld hints. The description adds details: probes each entity with ai_visibility_check, ranks, returns score/confidence/signal density. It could mention that it makes multiple calls and may be slower, but overall adds good context beyond annotations.

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

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

The description is four sentences, well-structured, and front-loaded. Each sentence adds value: core action, detail, use case, return format. No unnecessary words.

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

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

For a tool with 4 parameters, no output schema, and comprehensive annotations, the description covers purpose, usage, and return format adequately. It could mention that the tool internally calls ai_visibility_check, but it's not essential. Missing details like time cost or dep on external API are minor.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds value by specifying that the first entity is treated as 'subject' for narrative, which is not in the schema. This clarifies parameter semantics further.

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 compares AI visibility across multiple entities, uses ai_visibility_check internally, ranks results, and surfaces most/least recognized. It provides a concrete use case and distinguishes itself from siblings like ai_visibility_check and compare_entities.

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

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

The description gives a clear use case ('competitive AI-marketing audits') and example, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives like ai_visibility_check for single entities.

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 idempotent/readOnly annotations, the description adds behavioral traits: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed will list timeouts. 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 detailed but well-structured, front-loading the composite nature and use case. Slightly verbose with examples, but every sentence adds context. Could be slightly more concise, but overall effective.

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

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

Despite no output schema, the description explicitly enumerates the return fields (is_latest, license, advisory_count, bundle sizes, etc.) and explains partial failure behavior. This makes the tool fully understandable for invocation.

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

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

Schema description coverage is 100% for both parameters. The description adds value by clarifying that scoped packages are accepted for the 'package' param and that 'version' defaults to latest when omitted, which aids understanding beyond schema.

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

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

The description clearly states it is a composite check for evaluating npm packages, listing specific dimensions (license, advisories, version history, bundle size). It distinguishes from sibling tools by specifying NPM-only scope and mentioning alternative direct calls for other ecosystems.

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

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

Explicit usage guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also notes NPM-only in v1 and directs other ecosystems to deps.dev:version directly.

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

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

The description provides rich behavioral context beyond annotations: it explains the embedding model (BGE-base-en), windowing (500-char overlapping), character cap (200K chars with truncation flag), and that each passage includes an offset. 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 (~100 words), front-loaded with the core functionality, and uses clear prose without redundancy. Every sentence adds meaningful information.

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

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

Given the absence of an output schema, the description sufficiently explains return values (passages with offsets, scores) and limitations (input cap, truncation). The pairing advice with ask_pipeworx_grounded completes the usage context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the text parameter's max length, providing example queries, and clarifying the limit parameter's default and range. This exceeds baseline.

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

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

The description clearly states it performs semantic search inside a fetched record, and it distinguishes itself from siblings like ask_pipeworx_grounded by explicitly mentioning the pairing and use case. It uses specific verbs and resources.

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

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

The description explicitly says when to use the tool ('when the record is too big to cram into the prompt') and mentions a pairing strategy with ask_pipeworx_grounded. However, it does not explicitly state when not to use it, leaving minor ambiguity.

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

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

Annotations indicate a write operation (readOnlyHint=false) and side effects (openWorldHint=true), but the description adds significant behavioral context: subscription persistence, OAuth requirement, delivery channel limitations, and the one-time webhook secret. There is no contradiction with annotations.

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

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

The description is moderately lengthy but well-structured: opening sentence gives purpose and return, followed by requirements, type enumeration with examples, then delivery channels. It is front-loaded and each sentence adds value, though the delivery section could be slightly more condensed.

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

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

Given the tool's complexity (3 parameters, nested objects, multiple types), the description covers all necessary aspects: prerequisites, type-specific parameter guidance, delivery options, and limitations. No output schema is needed as the return value is simple and stated. The description is sufficient for correct invocation.

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

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

Schema coverage is 100%, and the description enriches each parameter with concrete examples and constraints beyond the schema (e.g., sec_8k items format, delivery validation rules). This addition significantly helps the agent select correct values.

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

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

The description clearly states the action ('Create a proactive monitoring subscription') and resource ('live-data event stream'), and specifies the return value ('Returns the new subscription id'). It distinguishes this tool from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation.

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

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

The description provides explicit usage context: requires a Pipeworx OAuth account, lists supported types with example parameters, and details delivery channel constraints (e.g., SMS verification, 10/day cap). However, it does not explicitly state when not to use this tool or mention alternatives beyond the given types.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds that it draws from a live catalog of thousands of tools and returns exact tool+argument shapes, enriching transparency.

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 example queries, then output description, then usage advice. Slightly lengthy but every sentence adds value; well-organized.

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

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

Despite no output schema, description fully explains return structure (category-bucketed examples with tool+argument shapes). Covers all needed context for a simple one-param 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 parameter. Description adds practical examples of topic values and explains consequence of omission (full spread), going beyond schema.

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

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

States clearly that it returns category-bucketed example questions with exact tool+argument shapes, serving as onboarding entry point. Distinguishes from siblings by being the first tool to call when unsure of Pipeworx capabilities.

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: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Also describes optional topic argument for focus.

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 critical behavioral context beyond annotations: it clarifies deactivation vs deletion (aligns with destructiveHint=false), idempotency (idempotentHint=true), and ownership constraints. This fully informs the agent of the tool's side effects and safety profile.

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 wasted words. The core action and key constraints are front-loaded. Every sentence adds value: purpose, ownership, and behavioral nuance.

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 single parameter, no output schema, and rich annotations, the description fully covers the tool's behavior. It tells how to use, what happens to data, and references related functionality ('historical events stay available via 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 description coverage is 100% (id parameter described as 'Subscription id (uuid) returned by subscribe.'). The tool description adds no further meaning to the parameter, so baseline score of 3 is appropriate.

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

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

The description states 'Cancel a subscription by id' with a specific verb ('Cancel') and resource ('subscription'). It clearly distinguishes from sibling tools like 'subscribe' by indicating it is the reverse operation and mentioning ownership enforcement.

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

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

The description explains ownership enforcement ('you can only cancel your own subscriptions') and the effect (deactivation, not deletion), which helps decide when to use. However, it does not explicitly mention that the id must come from a prior 'subscribe' call, though this is implied by the schema.

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

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

Annotations already indicate readOnlyHint, idempotentHint, etc. Description adds details: returns verdict, actual value with citation, reasoning; describes two processing paths and notes it replaces multiple sequential calls. 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 well-structured, front-loaded with examples and purpose. Every sentence adds value though slightly verbose. Efficiently communicates complex behavior.

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

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

Given complexity (two paths, two params, no output schema), description is thorough: explains when each path triggers, what the tool returns (verdict, value, citation, reasoning), and how tolerance works. No gaps.

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

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

Schema covers both parameters with descriptions. Description adds meaning: explains tolerance_pct overrides implied tolerance with usage example, and describes exact percent-delta math for financial claims. Compensates for lack of output schema by describing return structure.

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

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

Description clearly states it's for fact-checking natural-language claims against authoritative sources, with specific examples of user intents and distinct processing paths for financial vs other claims. It differentiates from sibling tools by focusing on verification and judgment.

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 the agent needs to check whether something a user said is factually correct.' Provides context on when financial claims use structured SEC path and others fall through to grounded pipeline. Lacks explicit when-not-to-use but context is clear.

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