Waqi

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

No annotations are provided, so the description must disclose behavior. It explains the routing and argument filling but lacks details on limits, processing time, or how ambiguous questions are handled. The mention of '300+ other sources' adds breadth but no depth on reliability or error handling.

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

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

The description is well-structured with a clear opening sentence, bullet-like list of sources, and examples. However, it's slightly verbose for a one-parameter tool; the list of sources could be condensed 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?

Given no output schema and a single parameter, the description covers the core functionality and scope adequately. It includes usage scope, examples, and source list. Missing details like query size limits or timeout behavior are minor issues in this context.

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

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

The input schema has 1 parameter ('question') with a description already covering it (100% coverage). The description adds examples but no new semantic constraints. With full schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's function: answering natural-language questions by automatically selecting the right data source. It provides a vivid list of data sources (SEC EDGAR, FRED, etc.) and concrete examples, making the purpose unmistakable and distinguishing it from sibling tools like specific lookup tools or 'discover_tools'.

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

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

The description gives explicit when-to-use guidance: when a user asks questions like 'What is X?' and you want to avoid picking the Pipeworx tool manually. It implies this is a fallback for unfamiliar queries, but doesn't explicitly state when not to use it (e.g., for known specific tools), which is a minor gap.

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

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

Discloses data sources (SEC EDGAR/XBRL, FAERS) and return format (paired data with citation URIs). No annotations exist, so description carries burden; could mention non-destructive nature or rate limits, but overall adequate.

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

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

Concise at ~100 words, front-loaded with core purpose, uses examples and bullet-like structure. No fluff.

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

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

Covers purpose, usage triggers, data sources, return format, and even replaces multiple sequential calls. No output schema, but description sufficiently explains what's returned.

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?

Adds significant meaning beyond schema: explains that 'type' determines data pulled (revenue/net income/cash/debt vs adverse events/approvals/trials), and 'values' require tickers/CIKs for companies or drug names for drugs. Schema has 100% coverage, but description enriches context.

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

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

Description clearly states 'compare 2–5 companies (or drugs) side by side', specifies exact data sources (SEC EDGAR/XBRL, FAERS), and distinguishes from 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?

Explicitly gives trigger phrases ('compare X and Y', 'X vs Y', 'how do X, Y, Z stack up') and explains when to use each type. Notes it replaces 8–15 sequential agent calls.

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

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

With no annotations, the description carries full burden. It explains that the tool returns 'top-N most relevant tools with names + descriptions,' which implies a read-only search operation. While it doesn't explicitly state non-destructive behavior or auth needs, the nature of the tool (discovery) makes these less critical. A minor gap is the lack of explanation about ranking criteria.

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 remarkably concise, consisting of two well-structured sentences that front-load the core purpose. Every sentence serves a clear function: stating the action, listing domains, and providing usage guidance. No wasted words.

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

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

Given the absence of an output schema, the description adequately explains the return value (tool names and descriptions). It also provides essential usage context (call first for exploration) and sufficient domain examples to cover expected use cases. The tool is simple, and the description fully equips an AI agent to use it correctly.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The tool description adds value by providing example queries (e.g., 'analyze housing market trends') and clarifying that the query should be a natural language description, which enhances the schema's baseline. The limit parameter is well-documented in schema, so no additional info needed.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It specifies the action (discover), the resource (tools), and provides concrete examples of domains (SEC filings, FDA drugs, etc.), distinguishing it from sibling tools that focus on individual entities or comparisons.

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

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

The description explicitly instructs when to use this tool: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear context and implicitly advises against using it when a single tool is already identified.

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

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

No annotations are provided, so the description carries full burden. It clearly discloses the output contents (SEC filings, financials, patents, news, LEI) and mentions pipeworx:// citation URIs. It does not discuss rate limits or authorization, but as a read operation this is acceptable. The transparency is high but not exhaustive.

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 are slightly verbose but each serves a purpose: first sentence states overall function, second provides usage examples and alternatives, third details inputs. The key information is front-loaded, though minor redundancy exists ('Get everything about a company' vs detailed list).

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

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

Without an output schema, the description fully explains what the tool returns, covering all major data categories. It also addresses input constraints and fallback behavior (resolve_entity for names). Given the tool's moderate complexity (2 parameters, simple types), the description is complete.

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

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

Schema coverage is 100% with both parameters described. The description adds valuable context: type is limited to 'company' for now, value expects ticker or zero-padded CIK, and names require resolve_entity first. This enriches the schema information.

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

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

The description opens with 'Get everything about a company in one call,' a specific verb+resource statement. It lists concrete data sources (SEC filings, fundamentals, patents, news, LEI) and distinguishes itself from sibling tools by positioning as a comprehensive alternative to calling multiple specialized tools.

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

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

The description explicitly states when to use (user queries like 'tell me about X', 'brief me on Tesla') and when not to (names not supported; directs to resolve_entity). It also explains the benefit over calling 10+ pack 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?

No annotations provided, so description carries burden. It discloses the destructive nature of deleting a memory. Lacks details on permanence or error handling, but sufficient for a simple operation.

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

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

Two concise sentences without waste. First sentence states action, second provides usage context and tool pairing.

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 delete operation with one parameter and no output schema, the description covers purpose, usage context, and sibling relationships adequately.

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

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

Schema coverage is 100%, and the description merely restates the schema's parameter description ('Memory key to delete'). No additional meaning added beyond schema.

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

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

The description clearly states it deletes a memory by key, with specific verb and resource. It distinguishes from siblings by mentioning 'remember' and 'recall' as related tools.

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

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

Explicitly lists when to use: stale context, task completion, clearing sensitive data. Provides pairing guidance with 'remember' and 'recall'.

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

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

No annotations provided, so description carries full burden. It discloses that the tool returns real-time data and lists outputs, but fails to mention any behavioral traits like caching, authentication needs, rate limits, or data recency guarantees. Adequate but not comprehensive.

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 sentence that is clear and to the point, listing all key outputs. Minor improvement could be breaking into multiple sentences for readability, but no wasted words earn a 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?

Given low complexity (1 param, no output schema), the description covers the return values sufficiently. It explains what the tool provides (AQI, pollutants, weather, station info), making it complete for a simple lookup tool.

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

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

Schema coverage is 100% with a clear description for the 'city' parameter. The description does not add new semantic value beyond the schema; it only restates that it's for a city and lists results. Per guidelines, baseline 3 is appropriate.

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

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

Description clearly states it retrieves real-time AQI for a city and lists specific returned data (AQI value, pollutants, weather, station info). It distinguishes itself from sibling tools like get_aqi_by_location and get_aqi_by_station by focusing on city name input.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage for city-based queries but does not mention when not to use it or provide context for choosing between the AQI 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?

With empty annotations, the description carries full burden. It states 'Real-time' indicating freshness, but does not disclose behavior if no station is found, distance limits, rate limits, or return format. The disclosure is minimal but not 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?

The description is a single, highly concise sentence that conveys all essential information. No wasted words; purpose, input, and output are front-loaded.

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

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

Given the tool's simplicity (2 required params, no output schema, no annotations), the description is largely sufficient. It explains input and output. A minor gap is not addressing what happens if no station is found nearby.

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 ('Latitude', 'Longitude'). The description adds the context that these are used to find the nearest station, which is a minor improvement over the schema alone. Baseline 3 is appropriate.

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

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

The description clearly states it returns 'Real-time AQI for the WAQI station nearest a lat/lon', specifying the resource (AQI), the data source (WAQI), the operation (nearest station), and input (lat/lon). This uniquely distinguishes it from siblings like get_aqi_by_city or get_aqi_by_station.

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

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

The description implies use when you have latitude/longitude coordinates, but provides no explicit guidance on when not to use this tool versus alternatives like get_aqi_by_city or get_aqi_by_station. No context about prerequisites or trade-offs is given.

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

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

No annotations provided, so description carries transparency burden. States 'Real-time AQI', but does not disclose potential rate limits, error handling, or guarantee of data availability. Adequate but not rich.

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 sentence with essential information: tool purpose, resource, and input type. No wasted words, front-loaded with the core action.

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

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

For a simple single-parameter tool with no output schema, the description adequately covers what the tool does and how to use the parameter. Refers to sibling tool search_stations for station discovery, completing the context.

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

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

Schema covers station_id with description, but description adds value by clarifying it is a 'numeric UID' and linking to search_stations, 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?

Description clearly states 'Real-time AQI for a specific WAQI station by UID (numeric)', specifying verb (get), resource (AQI for station), and identifier. Distinguishes from siblings like get_aqi_by_city and get_aqi_by_location by emphasizing the numeric UID input.

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?

Implies use when a numeric station UID is known, and the schema description notes the UID comes from search_stations, providing context. However, lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses rate limits (5 per identifier per day), free usage, and that it doesn't count against the tool-call quota. It also mentions the team reads digests daily, implying response time. It lacks details on side effects or confirmation, but for a feedback tool this is acceptable.

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

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

The description is a single paragraph that is front-loaded with purpose, then usage guidelines, then behavioral notes. Every sentence adds value, and it is concise without being terse. Slightly more structure (e.g., bullet points) could improve readability, but it is already effective.

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

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

Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, usage, parameters, and limitations (rate limits, quota) thoroughly. It could mention whether a confirmation is returned, but overall it provides sufficient context 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?

Schema description coverage is 100%, and the description adds significant context: it explains the 'type' enum values with examples, clarifies that 'context' is optional and what it relates to, and provides length guidelines and specificity for 'message'. It also adds advice beyond the schema, like not pasting prompts.

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 is for providing feedback (bugs, features, data gaps, praise) to the Pipeworx team, using specific verbs like 'Tell' and 'broken, missing, or needs to exist'. It distinguishes itself from sibling tools by being a feedback mechanism, not a data retrieval or analysis tool.

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

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

The description explicitly defines when to use each feedback type (bug, feature, data_gap, praise) and provides clear do's and don'ts, such as describing issues in terms of tools/packs and not pasting end-user prompts. It also mentions rate limits and that it doesn't count against quota.

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?

With no annotations provided, the description carries full burden. It discloses that the tool is scoped to the user's identifier and pairs with remember/forget, implying read-only behavior. It does not mention side effects, auth requirements beyond scoping, or rate limits, but the behavioral traits are reasonably covered for a simple retrieval tool.

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 succinct (three sentences) with front-loaded core action. Each sentence serves a purpose: definition, usage examples and context, scoping and pairing. No wasted words, and structured for efficient reading.

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

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

For a tool with 1 optional parameter, no output schema, and no annotations, the description covers purpose, usage context, examples, scoping, and relationship with siblings. However, it does not specify the return format (e.g., string or list structure), which is a minor gap in completeness.

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

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

The schema already provides 100% coverage for the single optional 'key' parameter with a clear description. The tool description repeats that omitting the key lists all saved keys, adding no new semantic information beyond what the schema offers. Thus baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as retrieving a stored value or listing all keys, with specific verb 'Retrieve' and resource 'value previously saved via remember'. It provides concrete examples (ticker, address, notes) and differentiates from siblings 'remember' and 'forget' by stating its retrieval role.

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

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

The description explicitly states when to use this tool: 'to look up context the agent stored earlier... without re-deriving it from scratch'. It also explains the effect of omitting the key argument (list all keys). However, it does not explicitly state when not to use it or suggest alternatives beyond related 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?

Despite no annotations, the description discloses that the tool fans out to three data sources, returns structured changes with counts and URIs, and explains the input format. It does not mention side effects or authentication, but the read-only nature is implied.

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 four sentences that cover purpose, usage, data sources, and return format. Every sentence adds value, and key information is front-loaded.

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

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

The description covers the tool's inputs, behavior (parallel fan-out), and outputs (structured changes, count, URIs). It lacks details on pagination or limits, but given the complexity and absence of output schema, it is sufficiently complete for effective use.

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%, providing a baseline of 3. The description adds value by clarifying the 'since' parameter format (ISO date or relative shorthand) and 'value' parameter (ticker or CIK), which goes beyond the schema definitions.

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: retrieving recent changes for a company from multiple sources (SEC EDGAR, GDELT, USPTO). It provides example user queries and distinguishes itself from sibling tools by focusing on temporal updates.

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

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

The description explicitly tells when to use the tool with natural language examples (e.g., 'what's happening with X?') and explains parameter semantics. It does not explicitly mention when not to use it or alternatives, but the context is clear.

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

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

No annotations, but description discloses persistence behavior (authenticated persistent, anonymous 24h). However, it does not clarify if writing to an existing key overwrites or errors, which would be helpful for a write operation.

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 concise sentences: purpose, usage guidance, and scoping. 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?

No output schema, but description adequately covers usage. Could mention return value (e.g., success indicator) but acceptable for a simple store 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?

Input schema provides full description of key and value with examples, so description adds little beyond that. Baseline 3 is appropriate.

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

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

Clearly states the tool saves data for reuse, with specific examples (resolved ticker, target address) and distinguishes from siblings recall and forget.

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

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

Explicitly tells when to use (when discovering something worth carrying forward), mentions pairing with recall and forget, and explains scoping and persistence differences.

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?

With no annotations provided, the description carries the full burden. It describes the output (IDs and pipeworx:// citation URIs) and gives examples. It lacks detail on rate limits, authentication, or error handling, but the core behavior is well communicated for a lookup tool.

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 five sentences, starting with the core purpose, then usage guidance, examples, workflow placement, and efficiency. No redundant information; every sentence adds value.

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

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

Given no output schema, the description explains the return format (IDs plus URIs) and provides examples. It covers essential aspects for an AI agent to use the tool correctly, though it might omit some edge cases (e.g., unsupported entity types).

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 by providing examples (e.g., 'Apple' → AAPL) and clarifying that 'value' can be a ticker, CIK, or name for companies, and brand or generic name for drugs. This enriches the schema definitions.

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

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

The description clearly states the action: 'Look up the canonical/official identifier for a company or drug.' It specifies the ID systems (CIK, ticker, RxCUI, LEI) and gives concrete examples, distinguishing it from sibling tools by explicitly saying to use it before other tools that need official identifiers.

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: 'Use when a user mentions a name and you need the CIK...' and 'Use this BEFORE calling other tools that need official identifiers.' It also notes it replaces 2-3 lookup calls, helping the agent decide when 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?

With no annotations, the description should disclose behavioral traits. It states inputs and outputs, implying a read operation, but does not explicitly confirm non-destructiveness, auth requirements, or response format details. For a simple search tool, this is adequate but not thorough.

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, front-loaded sentence that efficiently states the action, parameter scope, and return fields. Every word adds value, with no redundancy or irrelevant details.

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

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

The description omits details like handling of no results, multiple results, sorting, or pagination. With no output schema, the agent must infer these. While functional, it lacks completeness for a robust user experience.

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 describes 'keyword' as 'Search keyword' (100% coverage), but the description adds semantic value by clarifying that the keyword is a city or region name. This extra context helps the agent use the parameter correctly.

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

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

The description clearly states the tool searches stations by keyword (city/region name) and specifies the returned fields (UID, name, AQI, location). This distinguishes it from siblings like get_aqi_by_city or get_aqi_by_station, which require exact matches.

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

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

The description implies usage for searching by partial name, but does not explicitly guide the agent on when to use this tool versus alternatives (e.g., get_aqi_by_city for exact city, get_aqi_by_station for exact station ID). No when-not or alternative instructions are provided.

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

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

With no annotations, the description fully discloses the tool's behavior: it queries SEC EDGAR + XBRL, returns a verdict with structured data and citation, and replaces multiple sequential calls. No destructive actions are mentioned, and the output format is clearly described.

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 informative, covering purpose, usage, scope, and output in a single paragraph. It could be slightly more structured, but it efficiently conveys all necessary information without 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?

Given the single required parameter and no output schema, the description provides substantial context: the claim format, sources (SEC EDGAR + XBRL), possible verdicts, and efficiency gains. It lacks details on error handling or edge cases but is mostly complete for the intended use.

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 only parameter, 'claim', has 100% schema description coverage. The description reiterates the schema description without adding additional meaning, which aligns with the baseline score of 3 for high schema coverage.

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

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

The description clearly states the tool's function: fact-check, verify, validate, or confirm/refute a natural-language factual claim against authoritative sources. It specifies the supported domain (company-financial claims) and distinguishes it from other tools by its purpose and efficiency.

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 the tool: 'Use when an agent needs to check whether something a user said is true'. It also notes the scope limitation (v1 supports company-financial claims), implying when not to use it. However, it does not explicitly compare to sibling tools.

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