Open Meteo

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behaviors. The description adds that the tool is free and keyless (addressing auth requirements) and specifies a 5-day forecast range. It does not contradict annotations and provides useful context beyond the structured fields.

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 dense paragraph but is well-organized, starting with example queries and then detailing capabilities. It is concise (around 50 words) without fluff. A slightly more structured format (e.g., bullet points) could improve readability, but current form is effective.

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

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

Given that an output schema exists (though not shown here) and annotations cover safety, the description covers purpose, data types, time range, geographic scope, and access (free, keyless). It does not mention units or data resolution, but these are minor gaps. Overall, it is fairly complete for a simple data retrieval tool.

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

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

Schema coverage is 50% (hourly and forecast_days have descriptions; latitude and longitude do not). The description mentions default hourly variables and forecast_days range, adding some context beyond the schema. However, latitude and longitude remain undocumented both in schema and description, though their meaning is implied.

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

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

The description starts with common query patterns and explicitly states that the tool returns global air quality and pollen forecast data at any lat/lng, listing specific pollutants and pollen types. It clearly distinguishes the tool from weather-related siblings like 'forecast' or 'historical' by focusing on air quality metrics.

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 example use cases (air safety, pollution levels, smoke forecast, pollen) but does not explicitly state when not to use the tool or suggest alternatives among siblings. The guidance is implicit through examples, which is adequate but not proactive.

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. The description adds that Anthropic calls cost the user via their own key, and that the tool returns per-model {score, confidence, signals, raw_response} plus combined view. This adds value beyond annotations without contradiction.

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

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

Two sentences: first explains core function and defaults, second briefly lists use cases. No redundant words, clearly front-loaded with action and value.

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

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

Given the tool has 4 parameters, no output schema, and moderate complexity, the description adequately describes the return format and model distinction. It could mention any rate limits or pagination, but those are not present, so completeness is good.

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

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

Schema coverage is 100%, but the description adds context: default model, explanation that _apiKey is passed straight to Anthropic, and what context helps with. It clarifies how models parameter works and that omitting models uses only Workers AI.

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

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

The description clearly states it probes LLMs about a business/brand/product and returns a visibility score (0-100) per model. It specifies the verb 'probe', the resource 'LLMs', and the output 'score'. This distinguishes it from sibling tools like 'scan_competitor_ai_presence' which is more targeted.

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 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It explains the default vs. BYO model option (Workers AI vs Anthropic). While it doesn't state when not to use, the context is clear and provides alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds that the tool returns structured answers with stable pipeworx:// citation URIs and routes questions to the appropriate tool among 3,436, providing valuable behavioral 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 front-loaded with the core purpose and includes a list of domains and examples. It is slightly long but every sentence adds value, and the structure supports quick comprehension. A small reduction for not being as concise as possible.

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

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

The description covers purpose, usage, behavior, and examples comprehensively. While there is no output schema, the mention of structured answers with citations gives sufficient context. For a general query tool, this completeness is adequate, but missing details on return format prevent a perfect score.

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

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

Schema coverage is 100% with clear descriptions for all parameters including aliases. The description does not add much extra semantic detail for parameters, but the usage examples indirectly illustrate how to formulate questions. Given the high schema coverage, a baseline of 3 applies, but the examples push it to 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 that the tool routes questions to specialized tools across 780 sources and returns structured answers with citations. It distinguishes itself from web search and provides specific domains it covers, making the purpose very clear.

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

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

The description explicitly says to prefer this over web search for factual questions about real-world entities, events, or numbers. It gives concrete examples of when to use it, such as 'current US unemployment rate' or 'Apple's latest 10-K', leaving no ambiguity about appropriate usage.

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

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

Annotations already mark it as read-only, idempotent, non-destructive. The description adds rich behavioral context: it is hallucination-resistant, extracts answer only from tool result, returns explicit refusal reasons (not_in_source, no_tool_match, tool_error, etc.), and costs an extra LLM call. No contradiction.

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

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

Description is dense with key info front-loaded (purpose, behavior, return format). A bit long but each sentence serves a purpose. 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?

Given complexity and existing annotations, description covers purpose, behavior, return format (with fields), refusal reasons, use cases, and sibling comparison. 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%, so baseline is 3. The description notes question is natural language and lists aliases, but does not add deeper semantics beyond what schema provides.

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

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

The description clearly states it is a 'Hallucination-resistant answer mode for high-stakes reads' and explains the process: routing to the correct tool, extracting answer from tool result, and returning a structured response with evidence. It distinguishes itself from sibling ask_pipeworx by noting the extraction step and extra LLM call.

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

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

Explicitly states when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and when to prefer ask_pipeworx: 'for casual lookups'. Also notes cost tradeoff of one extra LLM call.

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

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

The description discloses detailed behavior: fan-out to data packs, resolver contract with confidence levels, parent event extractor, news fallback handling, safety measures for low-confidence and closed markets, and tradeability warnings. Annotations (readOnlyHint, idempotentHint) are 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?

The description is front-loaded with the main purpose and then provides well-organized details (classifiers, fan-out examples, response shapes, safety notes). However, it is quite verbose and could be more concise.

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 comprehensively covers input types, fan-out logic, response fields (market, analysis, evidence, resolver contract, parent event, news), and blocking conditions (low-confidence, closed markets, wide spreads). It provides complete and actionable context for an AI agent.

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

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

With 100% schema description coverage, the description goes beyond by explaining the market parameter accepts a slug, URL, or question text; depth controls thoroughness; include_raw toggles summary vs. full payloads. This adds significant semantic value.

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

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

The description clearly states the tool researches Polymarket bets, accepts multiple input formats (slug, URL, question text), and specifies the resource (Polymarket bet) with a specific verb (research/pull). It differentiates from siblings like polymarket_edges and polymarket_arbitrage.

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

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

The description explicitly provides use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z') and explains when results may be unreliable (low-confidence match, closed markets, wide spreads). However, it does not explicitly contrast with 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=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it pulls latest 10-K data for companies, handles off-calendar fiscal years correctly, returns paired data with citation URIs, and sorts results by primary metric. 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 thorough and front-loaded with the core purpose and usage hints. While it is somewhat long, every sentence adds value and there is no redundancy. A slight reduction in verbiage could improve conciseness, but it is 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?

Given the tool's complexity (2 required params, enum, array with constraints), the description is highly complete. It covers return format (paired data + citation URIs), sorting, entity-specific behaviors, and even handles edge cases like calendar year handling. No output schema exists, so description compensates fully.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema. It explains that 'type':'company' pulls revenue/net income/cash/debt from SEC EDGAR/XBRL and 'type':'drug' pulls FAERS/FDA/trial counts. It also clarifies that 'values' for companies are tickers/CIKs and for drugs are names, and that maxItems is 5.

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

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

The description clearly states the tool does side-by-side comparison of 2–5 companies or drugs in one parallel call, with specific examples of natural language triggers (e.g., 'compare X and Y', 'X vs Y'). It distinguishes itself from sequential single-pack lookups, which are sibling tools like entity_profile.

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

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

The description explicitly recommends this tool over sequential lookups when comparing entities (e.g., 'ALWAYS PREFER over sequential single-pack lookups'). It provides clear context for when to use it, including example queries and entity 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=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: returns top-N relevant tools with full schemas ready to call, no second lookup needed. No contradictions.

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

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

Well-structured with purpose upfront, examples, and usage note. Slightly verbose but generally efficient; earns its keep.

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

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

Given 6 params with full schema coverage and no output schema, the description fully covers the tool's role: returns top-N results with full schemas, suitable for discovery. 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%, so the schema itself documents all parameters. The description mentions 'query' is natural language and lists aliases, but adds little meaning beyond the schema.

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

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

The description clearly states 'Find tools by describing the data or task' with specific examples (SEC filings, financials, etc.), distinguishing it from sibling tools by recommending it as the first call to browse options.

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 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' providing clear when-to-use guidance and implying alternatives when a specific tool is known.

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

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

Beyond the annotations (readOnly, idempotent, etc.), the description details the parallel fan-out across multiple sources, specific returned data (e.g., recent_filings with URIs, fundamentals), and fallback behavior (GDELT→GNews, patent API sunset soft-fail). This gives the agent full awareness of the tool's behavior without surprises.

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 and front-loaded: it begins with example queries, then states the core purpose and usage preference, followed by a systematic breakdown of returned data. Every sentence is informative and not redundant, making it efficient despite 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?

Given the tool's complexity (multiple data sources, no output schema), the description thoroughly covers all aspects: input constraints, data sources, returned fields (including edge cases like patent API sunset), and fallback mechanisms. It positions the tool clearly among siblings as the holistic profile tool. 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?

The schema already covers both parameters with clear descriptions, including the constraint that value must be a ticker or CIK, not a name. The tool description reinforces this with concrete examples like 'AAPL' and '0000320193', and explicitly mentions using resolve_entity for names. This adds minor additional 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?

The description clearly defines the tool as returning a full cross-source profile of a US public company. It distinguishes itself from sibling tools by explicitly stating preference over chaining single-pack lookups and mentioning resolve_entity for name resolution. Examples like 'Tell me about X' and 'company profile for Microsoft' make the purpose immediately recognizable.

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

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

The description provides explicit guidance on when to use this tool: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also states when not to use it (names not supported) and directs to use resolve_entity first if only a name is available. This leaves no ambiguity for 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 readonly, idempotent, nondestructive. Description adds behavioral details: returns discharge in m³/s, up to 30 days, for any river-bearing lat/lng worldwide, and source (GloFAS). No contradiction.

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

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

Description is concise, front-loaded with example queries, and every sentence adds value. No superfluous 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?

Has output schema, so return values are partially covered. However, parameter details are missing, and with low schema coverage, the description should provide more context. Adequate but not 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 only 25% (low). Description does not explain parameters like 'daily' or 'forecast_days' beyond examples. Does not compensate for the low schema documentation.

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

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

Description clearly states it returns river discharge forecast for flood risk, with specific verb 'returns predicted m³/s discharge' and example queries. Distinguishes from sibling tools like generic 'forecast' by focusing on river flooding.

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

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

Explicitly states use cases: flood risk assessment, agriculture planning, hydrology research. Does not explicitly mention when not to use or alternatives, but context is clear.

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

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

Annotations already indicate read-only, idempotent behavior. The description adds that the tool is free, keyless, and sourced from Open-Meteo/ECMWF, and details default output variables like temperature, precipitation, wind, humidity, cloud cover, and weather codes.

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 dense paragraph that efficiently conveys key information, including example queries, capabilities, and usage tips. It is well front-loaded but could benefit from slight structuring (e.g., bullet points) for easier scanning.

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 essential input requirements, customization options, output details, data sources, and integration with geocode. It is fully sufficient for an agent to understand and correctly invoke the tool.

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

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

The description explains that hourly/daily parameters allow custom variables, complementing the schema's parameter descriptions. It provides context that default sensible sets are used, and clarifies the need for lat/lng coordinates, which is valuable beyond the schema's field descriptions.

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

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

The description clearly states the tool provides weather forecasts for any location globally, up to 16 days ahead, hourly or daily. It lists typical user queries and distinguishes itself from sibling tools like air_quality, flood, and marine by focusing on general weather.

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 example prompts and advises pairing with geocode to convert city names to lat/lng. While it doesn't explicitly state when not to use the tool, the sibling context and clear scope make usage context 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?

Describes the destructive action (delete) and reasons for use. Annotations include destructiveHint=true and idempotentHint=true, which align with the description. Does not explicitly mention idempotency or error handling for missing keys, but 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?

Two sentences that are efficient and front-loaded: first states the action, second provides usage scenarios. 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 single-parameter tool with no output schema, the description covers purpose, usage context, and relationships with siblings. Annotations provide safety cues. Complete for the tool's complexity.

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

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

Schema coverage is 100% with a single parameter 'key' described as 'Memory key to delete'. The description adds minimal additional meaning ('by key'), so baseline of 3 is appropriate.

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

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

The description clearly states 'Delete a previously stored memory by key', which uses a specific verb and resource. It distinguishes itself from siblings like 'remember' and 'recall'.

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

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

Provides explicit scenarios for use: stale context, task completion, clearing sensitive data. Mentions pairing with remember and recall. Lacks explicit when-not-to-use but offers strong positive guidance.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds 'fetches page, extracts title/description/key links, emits standard markdown'. No contradictions.

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

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

Three sentences, front-loaded with main action, then details, then use cases. 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?

Low complexity tool with good annotations. Description explains output format and deployment location. No output schema needed.

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 at 100%. Description repeats default/max for max_links already in schema. Adds no new semantic value.

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

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

Clearly states verb 'generate' and resource 'llms.txt file for any URL'. Specifies purpose for AI crawlers and output format. No sibling overlap as none generate llms.txt.

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

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

Explicitly lists three use cases (client indexing, personal project, competitor audit). Does not provide exclusions or alternatives, but context is strong.

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

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

Annotations already indicate read-only, idempotent, open-world, non-destructive behavior. The description adds valuable context: free, keyless, multilingual, returns up to 100 matches ranked by population. 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 two focused sentences. First sentence captures purpose and examples, second provides usage guidance. 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?

Given the presence of an output schema and full parameter descriptions, the description is complete. It covers purpose, usage context, behavioral traits, and parameter semantics adequately.

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

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

Schema coverage is 100% with parameter descriptions. The description adds meaning beyond schema by explaining the population ranking, multilingual support, and the maximum results count. Examples reinforce 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 states the tool resolves place names to lat/lng coordinates for use with other Open-Meteo tools. It uses specific verbs ('resolve') and resources ('place name to lat/lng') and distinguishes from siblings by indicating it is a preparatory step.

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 before forecast / historical / air_quality / marine / flood when you only have a place name.' This provides clear when-to-use context and implies alternatives when coordinates are already available.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns hourly/daily variables for any date range but does not disclose additional behavioral traits like rate limits, accuracy, or data sources beyond ERA5.

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

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

The description is a single, well-structured sentence that front-loads user intent examples followed by technical details. It is concise and avoids redundancy, though a bit more structure (e.g., bullet points for parameters) could improve scannability.

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

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

Given the presence of an output schema (not shown here but declared in context), the description adequately covers return types (temperature, precipitation, etc.). It differentiates from weather-related siblings and provides sufficient detail for the tool's complexity.

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

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

Schema description coverage is only 29%, but the description compensates with examples (e.g., 'daily': 'temperature_2m_max,precipitation_sum') that clarify parameter usage. It explains that hourly/daily parameters select variables, adding meaning beyond the sparse schema descriptions.

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

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

The description uses example queries to immediately convey the tool's purpose: retrieving historical weather data from ERA5 reanalysis. It specifies the data source, time range (1940-present), and global coverage, clearly differentiating from sibling tools like 'forecast'.

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 use cases: climate analysis, retrospective event weather, training data. While it doesn't mention when not to use or alternatives, the sibling 'forecast' implies a clear boundary, and the context is sufficient.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the description's disclosure of behavioral traits is supplementary. It adds that the tool returns specific fields and defaults to active subscriptions, but does not provide extensive additional behavioral context beyond what annotations cover.

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

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

The description is concise with three sentences, each adding value. The first sentence clearly states the purpose and return fields, which is front-loaded. No extraneous 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?

The description adequately covers the tool's purpose, return fields, and usage context. Given the tool's simplicity (single optional parameter, no output schema), the description is sufficiently complete. It does not elaborate on formatting or limits, but these are minor omissions for a listing tool.

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

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

The input schema already provides complete description for the single parameter (include_inactive). The tool description does not add further semantic detail about the parameter, so it meets the baseline for high schema coverage.

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

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

The description uses a specific verb 'List' and resource 'caller's subscriptions', specifies the return fields, and distinguishes from sibling tools like subscribe/unsubscribe by focusing on listing active subscriptions. It also provides context on when to use it.

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

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

The description provides explicit usage scenarios: review before adding subscriptions or find an ID for cancellation. This clearly guides when to invoke this tool versus its siblings. However, it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so safety profile is covered. The description adds behavioral context: free, keyless, global coverage, and specifics on output (wind waves, swell waves). No contradictions. Score 4 for adding value beyond annotations.

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

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

The description is a single, efficient sentence front-loaded with example queries, followed by the definition. No redundancies. Every phrase adds value. Could be slightly more structured, but it is concise and clear. Score 4.

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 and an output schema (not shown), the description covers usage, output categories, and typical applications. It does not detail return format but the output schema exists to handle that. Sufficient for agent invocation. Score 4.

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 low (25%), with only 'hourly' described. The description provides examples with latitude, longitude, and optional forecast_days, but does not explicitly define each parameter. This partially compensates for the schema gap. Score 3: baseline adjusted upward slightly for examples but still lacking explicit semantics.

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

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

The description clearly states it provides a global marine weather forecast (wave height, period, direction, etc.) at any ocean lat/lng. It gives example queries. However, it does not explicitly differentiate from sibling tools like 'forecast' or 'flood', though the focus on marine conditions is implicit. Score 4 because the verb 'get forecast' is implied and the resource is specific.

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

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

The description lists use cases: surf reports, sailing prep, fishing conditions, coastal planning. It implies when to use but does not provide exclusions or alternatives. No guidance on when not to use vs siblings. Score 3 for clear context without explicit when-not or alternative references.

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

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

Beyond the annotations (which are minimal), the description adds important behavioral details: rate-limited to 5 per identifier per day, free usage, and that it doesn't count against tool-call quota. 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?

Concise and well-structured. Begins with the main action, followed by use cases, guidelines, and rate limits. Every sentence is informative and necessary.

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 feedback tool with no output schema, the description covers all necessary aspects: input, usage context, constraints. The agent can confidently decide when and how to invoke it.

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

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

Schema coverage is 100% with good descriptions for each parameter. The description adds extra value by advising on message specificity (1-2 sentences, 2000 chars max), which complements the schema.

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

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

The description clearly states the tool's purpose: providing feedback to Pipeworx about bugs, features, data gaps, or praise. It distinguishes itself from sibling tools, all of which serve different functions.

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: for bugs, feature requests, data gaps, or praise. Also provides guidance on what not to do (avoid pasting end-user prompts) and how to structure feedback.

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

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

Adds significant value beyond annotations: discloses data source (CF analytics-engine), no PII, cached 5min-1h. Annotations already show readOnly/idenpotent/non-destructive; description enriches with source and caching behavior.

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

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

Well-structured with core statement first, then usage scenarios, then technical detail. Slightly lengthy but each sentence adds value. Could be trimmed slightly 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?

For a simple tool with 1 param and no output schema, description covers purpose, usage, behavior, and parameter semantics completely. No gaps given complexity.

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

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

Schema coverage 100% with enum description. Description adds extra context: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' This elevates meaning beyond schema.

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

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

Clearly states it returns top tools, top packs, and total call volume over a window. Specific verb 'returns', resource 'trending data on Pipeworx'. Distinguishes from siblings like 'ask_pipeworx' by focusing on aggregated agent activity.

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

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

Explicitly lists three use cases: discovering hot data sources, confirming canonical choices, and checking use case alignment. Lacks explicit when-not-to-use but provides strong contextual guidance.

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

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

Annotations already indicate read-only and idempotent. Description adds rich behavioral details: monotonicity checks (date-axis, threshold-axis ordering), partition sum check, semantic anchor Jaccard similarity, partition filter for placeholders, response structure including opportunities and partition_check. 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 dense but well-structured with sections (SEMANTIC ANCHOR, PARTITION FILTER). Front-loaded with key requirement. Could be slightly more concise without losing nuance, but every sentence adds value.

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

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

Given complexity of tool and absence of output schema, description thoroughly explains return values (opportunities[] fields, partition_check), edge cases (skipped_low_similarity, placeholder fraction), and both modes' behaviors. Sufficient for an agent to correctly invoke and interpret results.

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

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

Schema coverage is 100% with basic descriptions. Description adds substantial meaning: concrete examples of slugs and seed questions, explains what happens in each mode, details the checks performed based on parameter choice. Significantly enhances parameter 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?

Clearly states it finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. Distinguishes between single-event and cross-event modes with specific slugs and seed question examples. Differentiated from sibling tools like polymarket_edges and polymarket_kalshi_spread.

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 that one of `event` or `topic` is required, and call with no args fails. Provides guidance on when to use each mode (event for specific market, topic for scanning related events). Includes examples and explains cross-event mode catches patterns missed by single-event mode.

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

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

The description goes far beyond the annotations (readOnlyHint=true, etc.) by detailing the model families, edge calculations (lognormal barrier, news momentum), Kelly sizing, slippage assumptions, 24h-move warnings, tradeable-edge filters, response structure with diagnostics, and caching behavior ('Cached 1h at the KV level'). It also explains edge cases like Fed bets and empty segments.

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 excessively long and dense, approaching a specification document. While it is structured with clear sections (e.g., 'FIVE MODEL FAMILIES grouped into three response segments'), the sheer volume of detail undermines conciseness. Every sentence is informative, but the length risks overwhelming an agent or human reader.

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

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

Despite lacking an output schema, the description thoroughly explains the response structure (by_segment, fed_candidates, diagnostics), edge case handling (empty segments, stale data, filter skips), and the meaning of returned fields (edge_pp_net, kelly_fraction, liquidity, etc.). It covers all necessary context for an agent to understand and use the tool effectively.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the interplay between parameters (e.g., min_kelly vs min_partition_leg_kelly, slippage_pp usage, tradeable-edge knobs context). It provides practical guidance on default values and scenarios for adjustment, enhancing understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It specifies the action (scanning), the resource (Polymarket markets), and the unique value (Pipeworx data disagreement). It also distinguishes this tool from potential siblings by focusing on opportunity discovery without paging through hundreds of markets.

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

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

The description provides clear context for when to use this tool: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It explains the tradeable-edge knobs and filters, giving guidance on how to adjust parameters. However, it does not explicitly state when not to use this tool or mention alternatives like polymarket_arbitrage.

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 safety fields (compatibility_warning, temporal_alignment), explaining why spreads may be invalid (non-equivalent bet shapes, temporal misalignment), and noting that most pre-mapped topics return warnings. It also clarifies that the tool's output may not imply tradability. This provides substantial behavioral context beyond the annotations' readOnlyHint, openWorldHint, idempotentHint, and destructiveHint.

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

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

The description is comprehensive (298 words) but well-structured with clear sections (TWO MODES, RESPONSE, SAFETY FIELDS). Each sentence adds value, though some detail could be condensed. It front-loads the core purpose and uses formatting (bold) for emphasis. It is appropriate for the tool's complexity.

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

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

Given the absence of an output schema, the description adequately explains the response structure (leg-by-leg prices, spreads, safety fields) and the conditions affecting spread validity. It covers most necessary aspects for an agent to use the tool correctly, though the exact format of the response could be more explicitly described.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the two modes, how explicit parameters override topic mappings, and listing the pre-mapped topics. It also clarifies the interaction between parameters. This exceeds the schema descriptions, justifying a 4.

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

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

The description clearly states the tool's purpose: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It uses a specific verb (spread) and identifies the resources (Kalshi and Polymarket). The scope is well-defined, and it distinguishes itself from sibling tools like polymarket_arbitrage or compare_entities by focusing on cross-venue spreads.

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

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

The description explains two modes (topic and explicit) and when to use each. It also provides guidance on when not to rely on the spread, such as when compatibility_warning fires or when temporal_alignment is false. However, it does not explicitly mention alternative tools or situations where another tool would be preferable, limiting the score to 4.

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. Description adds scope details (anonymous IP, BYO key hash, or account ID) which is helpful beyond annotations. No contradictions.

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

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

Three sentences, each purposeful. First states core function, second gives use cases, third explains scope and pairing. Front-loaded with key action, no waste.

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

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

Despite no output schema, description fully explains behavior, use case, scope, and relationships to sibling tools. Leaves no ambiguity for agent selection and 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 has 100% coverage with one optional parameter well-described. Description adds the critical detail that omitting key lists all saved keys, which is not in the schema. Provides extra usage clarity.

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

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

Description clearly states the tool retrieves a value by key or lists all keys if key is omitted. Provides concrete examples (user's target ticker, address, research notes) and distinguishes from siblings (remember, 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?

Explicitly says when to use: to look up stored context without re-deriving. Describes scope by identifier and pairs with remember (save) and forget (delete). No 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 already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe read-only behavior. The description adds specific behavioral details: that mark_read flags events as read for subsequent calls, and that polling works fine. 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, with 5 sentences that front-load the purpose. Every sentence adds unique value, covering functionality, filtering, and alternative access 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?

Although there is no output schema, the description explains the return fields (source, citation_uri, raw payload) and mentions the feed is persisted. It adequately covers filtering and behavior for a read-only tool, though exact response structure could be more explicit.

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

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

Schema description coverage is 100%, but the description enriches parameter meaning with examples (e.g., 'sec_8k' for type), clarifies ISO timestamp format for since, and explains the effect of mark_read and unread_only flags. This adds value beyond the schema.

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

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

The description clearly states the tool pulls fired events from a subscription feed, specifying the verb 'pull' and the resource 'fired events from your subscription feed'. It explains the returned data includes source, citation_uri, and raw payload, which distinguishes it from sibling tools like 'subscribe' or 'unsubscribe'.

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

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

The description mentions polling works fine and provides an alternative HTTP endpoint for scripts/dashboards, giving context on when to use the tool versus other access methods. However, it does not explicitly state when not to use it or compare to other tools like 'ask_pipeworx'.

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. The description adds valuable behavioral context: parallel fan-out to multiple sources, fallback behavior (GDELT→GNews), soft-failure for USPTO, and return structure (grouped changes, total count, URIs). 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 slightly lengthy but front-loaded with example queries and efficiently organized. Every sentence adds value, though some redundancy could be trimmed. Still, it is well-structured and clear.

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

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

No output schema exists, but the description adequately specifies the return format (grouped changes, total count, citation URIs). It covers complex behavior (multiple sources, fallback, parameter formats) completely for the tool's scope.

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

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

Schema covers all 3 parameters (100% coverage). The description enhances semantics with examples for 'since' (ISO date and relative shorthand), typical usage advice, and explanation of 'value' as ticker or CIK. This adds meaningful guidance 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 provides a change feed for a company over a time window, listing specific data sources (SEC EDGAR, GDELT→GNews, USPTO) and explicitly contrasts with sibling tool entity_profile, making it easy to distinguish.

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

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

The description includes example queries (e.g., 'What's new with X') and directs to use entity_profile for static profiles. It explains input formats for 'since' and typical usage, though it does not explicitly 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 provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context about key-value scoping and retention (persistent for authenticated, 24 hours for anonymous). It does not contradict annotations and adds valuable behavioral details beyond what annotations convey.

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 enough, with each sentence adding value: purpose, usage, persistence, sibling references. It is front-loaded with the main action. While slightly longer than necessary, it is well-structured and informative.

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

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

Given the simplicity (2 string params, no output schema), the description covers all necessary context: what it does, when to use, how long data persists, and how to retrieve/delete. It is fully complete for an agent to use the tool correctly.

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

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

Input schema has 100% description coverage for both parameters, so the description adds no additional parameter semantics. The baseline is 3 as per guidelines; no extra value is provided beyond the schema.

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

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

The description clearly states 'Save data the agent will need to reuse later' and gives specific examples like resolved ticker, target address, user preference. It also distinguishes from sibling tools recall and forget by mentioning them. This provides a clear purpose and differentiation.

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

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

The description explicitly says 'Use when you discover something worth carrying forward...' and explains the persistence difference between authenticated and anonymous users. It also directs to recall for retrieval and forget for deletion, providing clear guidance on when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. Description adds behavioral context: internal cascading through multiple endpoints, replacing manual lookups. 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 somewhat long (about 100 words) but well-structured: starts with examples, then states core purpose, then details supported types. Every sentence adds value, no fluff. Appropriate for the complexity of the tool.

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

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

Given no output schema, the description adequately explains return values for each type (ticker, CIK, company_name, citation URI for company; RxCUI, ingredient, brand for drug). Covers key aspects like citation URIs and auto-disambiguation.

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

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

Input schema has 100% coverage with descriptions, so baseline is 3. Description adds significant detail beyond schema: for 'type' lists supported values (company, drug), for 'value' gives concrete examples (AAPL, ozempic) and explains return format per type (ticker, CIK, RxCUI).

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

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

Description uses specific verbs ('resolve', 'look up') and resources (names to canonical IDs), provides clear examples for each supported type (company, drug), and distinguishes itself from sibling tools by claiming it replaces 2-3 manual lookups.

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

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

Clearly states 'Use FIRST whenever you have a name but need an ID', providing explicit context for when to use. Does not explicitly mention when not to use or alternative tools, but the context from sibling names implies differentiation.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by explaining the internal process (probing each entity with ai_visibility_check, ranking, and returning score/confidence/signal density), which goes beyond the annotation 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?

Three sentences: first states purpose, second explains mechanism, third gives use case and return format. Every sentence adds value; no filler. Front-loads core action.

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

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

With 4 parameters, 1 required, and no output schema, the description covers purpose, usage, and output structure (ranked list with fields). It could mention the entity count range (2-8) explicitly, but schema covers it. Overall complete for a comparison tool.

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

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

Schema description coverage is 100%, but the description adds meaning: for 'entities' it specifies the first is the subject, for 'models' it lists supported values and defaults, and for 'context' it clarifies the role. This surpasses the baseline 3.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using specific verb 'Compare' and resource 'AI visibility across multiple entities'. It distinguishes from sibling 'ai_visibility_check' by noting it aggregates multiple probes and from 'compare_entities' by specifying the context of AI-marketing audits.

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 a clear use case ('competitive AI-marketing audits') and a specific example question, but does not explicitly state when not to use it or mention alternatives like the single-entity 'ai_visibility_check'.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds significant behavioral details: fan-out to two services, specific return fields, partial failures with sources_failed, and bundlephobia's first measurement latency (5-30s). No contradiction with annotations.

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

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

Well-structured and front-loaded with purpose. Every sentence adds value, though slightly verbose. Could be trimmed without losing substance.

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

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

Given no output schema, the description thoroughly explains the return format (summary, advisories, links, alternative versions), failure modes, and ecosystem boundaries. Provides full context for an agent to invoke correctly.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds context about scoped packages, default version behavior, and what each service contributes, enhancing the understanding beyond the schema.

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

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

The description clearly states it is a composite check for adding an npm package, detailing the services fanned out (deps.dev and bundlephobia) and the return fields. It distinguishes from siblings by specifying NPM ecosystem only and referencing deps.dev:version 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?

Provides explicit when-to-use scenarios ('is X safe / popular / small' and 'what does adding lodash cost me'). Mentions graceful degradation and ecosystem limitation, but does not explicitly state when not to use. However, the context is clear enough for correct selection.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint; description adds technical details: BGE-base-en embeddings, cosine similarity, 500-char windows, 200K char cap with truncation flagged, and passage offsets for verification. 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?

Single paragraph is front-loaded with purpose, then usage, then technical details. Every sentence earns its place with no redundancy or fluff.

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

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

Though no output schema, description explains return format: 'top-N passages with character offsets and similarity scores.' Also covers input limits and algorithm. Complete for a search 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%, so baseline is 3. Description adds value with examples for query parameter and notes default limit of 5, improving clarity beyond schema descriptions.

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

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

The description clearly states 'Semantic search INSIDE a fetched record' with specific verb and resource, and distinguishes itself from siblings like ask_pipeworx_grounded by explaining the fetch-then-search workflow.

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 when the record is too big to cram into the prompt' and provides practical examples (SEC 10-K, article, long tool result). Also pairs with ask_pipeworx_grounded, giving clear context for usage.

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

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

The description states the tool 'Creates' a subscription, which is a write/mutative operation, but the annotations declare readOnlyHint=true, creating a contradiction. Beyond this, the description does not disclose potential side effects, idempotency, or other behavioral traits not captured in annotations. The contradiction drastically reduces 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?

The description is well-structured and concise. It starts with the verb and purpose, explains the type with examples, mentions prerequisites, and details delivery channels. Every sentence adds 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?

Given the complexity (3 parameters, nested objects, no output schema), the description covers essential details: return value (subscription id), prerequisites, type-specific filtering, delivery options, and operational constraints (SMS cap). Minor omissions include absence of error handling or explicit confirmation behavior.

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

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

The input schema has 100% coverage, providing a baseline of 3. The description adds significant value by explaining the enum 'sec_8k', giving concrete examples for the 'params' object (ticker, items), detailing 'delivery' fields with formatting and rate limits (e.g., SMS cap at 10/day), and clarifying defaults (items default to all).

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream, specifies the supported type 'sec_8k', and explains its purpose with concrete examples like items for 8-K filings. It distinguishes itself from sibling tools like 'list_subscriptions' and 'unsubscribe' by focusing on creation.

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

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

The description provides context on when to use this tool: for monitoring specific events via subscription. It mentions prerequisites (Pipeworx OAuth account) and delivery channels (feed always on, optional email/SMS). However, it does not explicitly contrast with alternative tools like 'recent_alerts' or 'list_subscriptions', leaving some ambiguity for 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?

The description says 'Cancel a subscription' and 'row is deactivated', indicating a write/mutation operation. However, annotations include readOnlyHint: true, which claims the tool does not change state. This is a clear contradiction, making the description misleading.

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

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

Two sentences with no wasted words. The action is front-loaded and the explanation of ownership and deactivation is efficient.

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

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

The description covers ownership, deactivation, and historical retention, which is sufficient for a simple tool. However, the annotation contradiction undermines trust and completeness, preventing a higher score.

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

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

The schema already provides a clear description for the only parameter id. The description reinforces that it's a subscription id but adds no extra semantics beyond the schema.

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

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

The description clearly states 'Cancel a subscription by id', using a specific verb and resource. It distinguishes from sibling tools like subscribe (create) and list_subscriptions (read).

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'), providing clear context. It does not explicitly list when not to use or name alternatives, but the sibling tool names imply the opposite operation.

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, open-world, and idempotent behavior. The description adds valuable context: the return types (verdicts like 'confirmed' or 'refuted'), the inclusion of extracted structured form, actual values with citations, and percent delta. 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 and well-structured, starting with natural-language triggers and then detailing functionality, scope, and return format. Each sentence adds information; there is minimal fluff. Could be slightly shorter but still 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?

For a tool with one parameter and no output schema, the description is remarkably complete. It explains the input type, supported evidence sources, output verdict options, and how it differs from a multi-tool approach. The annotations cover safety and idempotency, so all relevant context is 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?

The sole parameter 'claim' has a clear description in the schema. The tool description adds examples of natural-language claims and clarifies the expected format. Schema coverage is 100%, so the description goes beyond by providing usage context and acceptable input patterns.

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

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

The description clearly states the tool's purpose: natural-language claim verification against authoritative sources. It includes explicit trigger phrases and specifies the domain (company-financial claims) and data sources (SEC EDGAR + XBRL). It distinguishes itself from siblings by claiming to replace 4-6 sequential calls.

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

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

The description provides clear guidance: use it when the agent needs to fact-check a user's statement. It specifies the supported scope (public US company financial claims) but does not explicitly state when not to use it or list alternatives beyond the implicit replacement note.

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