Open Meteo

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

With no annotations, the description fails to disclose any behavioral traits such as read-only nature, required permissions, or output format. It only lists pollutants.

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

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

The description is extremely short but under-specified, relying on a comma-separated list without sentences or structure, which harms 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 4 parameters, no output schema, and empty annotations, the description is severely inadequate. It omits return format, limitations, and most usage context.

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

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

The description adds no meaning to parameters beyond the schema's own descriptions for hourly and forecast_days. It does not explain latitude/longitude or compensate for missing 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 lists pollutant names but lacks a verb or resource, making it unclear that the tool retrieves air quality data. It does not explicitly state the action or the data type.

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

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

No guidance on when to use this tool versus siblings like forecast or flood. The description does not mention scenarios or conditions.

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 for behavioral disclosure. It describes the tool as automatically picking the right data source and routing, but does not disclose limitations, error handling, what happens if the question is ambiguous, or any potential costs or rate limits. This lack of transparency for a tool that makes autonomous decisions is a significant gap.

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 paragraph of about 5 sentences. It is front-loaded with the main purpose and contains relevant information without fluff. It could be slightly more concise, but overall it is well-structured and efficient.

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

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

Given the tool's complexity (routing across 300+ sources), the description covers the what and when well. However, it lacks information about the output format (e.g., returns text, JSON) and any potential limitations. With no output schema, the description should provide more context about what the agent can expect as a result. Hence 3.

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% (only one parameter 'question' with description). The description adds value by providing example questions and clarifying the scope of sources. Since the schema already describes the parameter, the baseline is 3, and the examples raise 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 uses a specific verb ('answer a natural-language question') and resource ('automatically picking the right data source'). It lists multiple examples and source domains, clearly distinguishing it from sibling tools that are likely more specific. This is a 5.

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

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

The description explicitly states when to use the tool: 'Use when a user asks... and you don't want to figure out which Pipeworx pack/tool to call.' It provides example queries. However, it does not mention when not to use it or explicitly name sibling alternatives, which would make it a 5. Thus 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?

No annotations, so description carries full burden. It discloses data sources (SEC EDGAR/XBRL, FAERS, etc.) and returned content (paired data + URIs). No mention of destructive or side effects, but likely read-only.

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?

Approximately 100 words, front-loaded with main purpose, includes examples and use cases. No redundant 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?

Fairly complete for agent decision-making: explains what data is pulled for each type and mentions return format (paired data + URIs). Could be more specific about output structure, but sufficient.

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

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

Schema has 100% description coverage. Description adds context by explaining values for each type and giving examples (e.g., 'AAPL','MSFT' for company). Adds meaningful value beyond schema.

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

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

Description clearly states the tool compares 2-5 companies or drugs side by side, with specific verb 'compare' and resource 'entities'. It distinguishes from siblings by noting it replaces 8-15 sequential agent 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?

Explicitly lists when to use (e.g., 'compare X and Y', 'X vs Y') and provides context for each type. Does not state when not to use, but guidance 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 provided, so the description must carry the behavioral burden. It states the tool returns 'top-N most relevant tools with names + descriptions', implying a read-only search operation. However, it does not disclose any potential errors, rate limits, or other behavioral traits beyond the basic output.

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 4 sentences long, front-loads the core purpose, and uses bullet-like lists for examples. Every sentence adds necessary detail without redundancy, making it highly efficient.

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

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

Given no output schema, the description minimally explains the return format ('top-N most relevant tools with names + descriptions'). This is sufficient for a simple discovery tool, but additional details about the structure (e.g., whether it's a list of objects) would improve completeness.

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

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

Schema descriptions cover both parameters (query and limit) at 100%, but the description adds value by explaining that limit controls the number of results and providing natural language examples for the query parameter, enhancing the schema's information.

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

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

The description clearly states 'Find tools by describing the data or task' and provides a long list of example domains (SEC filings, FDA drugs, etc.), making the purpose explicit and distinguishing it from sibling tools that target specific data sources.

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 you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set.' This guides agents on when to invoke it, though it doesn't 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?

With no annotations, the description carries the transparency burden. It adequately describes the tool as a read operation returning multiple data types, mentions supported entity types (only company), and notes citation URIs. However, it does not explicitly state that no modifications occur, nor does it mention error handling or limitations beyond entity type.

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 five well-structured sentences. The main purpose is front-loaded, followed by usage patterns, return contents, citation format, and input instructions. Every sentence provides essential information 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 tool's complexity (aggregating across multiple data sources) and the absence of an output schema, the description covers the main return categories and input requirements. However, it could be more complete by mentioning error conditions (e.g., invalid ticker) or the exact structure of the output.

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

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

Schema coverage is 100%, and the description adds significant value beyond the schema. It explains that the 'type' parameter currently only supports 'company' with future plans, and for 'value' it clarifies the acceptable formats (ticker or zero-padded CIK) and when to use resolve_entity for names.

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

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

The description clearly states the tool's purpose as getting all information about a company in one call, using specific verbs and resources. It lists the data categories returned (SEC filings, financials, patents, news, LEI) and distinguishes itself from siblings by noting it replaces multiple separate tool 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 explicitly states when to use (e.g., 'tell me about X', 'research Microsoft') and provides clear prerequisites: use a ticker or CIK, and if only a name is available, use resolve_entity first. This guidance helps the agent select the appropriate 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?

With no annotations, the description must disclose behavioral traits, but it only states it is a 'Daily river discharge forecast'. It omits details like return format, time range, units, error handling, or requirements such as date parameters.

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

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

The description is a single sentence, which is concise but at the expense of completeness. It lacks essential context for a tool with four parameters and no annotations, making it under-specified.

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

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

Given four parameters, two required, and no output schema, the description is severely incomplete. It fails to explain required parameters (latitude, longitude), optional ones (daily, forecast_days), or what the output contains, rendering it inadequate for correct tool selection.

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%), yet the description adds no parameter meaning beyond what the schema provides. It does not explain 'latitude', 'longitude', or 'forecast_days', leaving the agent to guess their roles.

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 'Daily river discharge forecast' from the 'GloFAS model', which is a specific verb and resource. It distinguishes effectively from sibling tools like 'air_quality', 'marine', and 'forecast' which cover different domains.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools exist (e.g., 'forecast', 'historical'), but the description offers no comparative context or prerequisites, leaving the agent to infer usage context.

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

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

Annotations are absent, so the description must convey behavior. It states the tool provides forecast data, which implies a read operation. However, it does not disclose any side effects, authentication needs, or data format details, leaving gaps for an agent.

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

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

The description is a single sentence with no filler, front-loading the core purpose. Every word is informative and efficient.

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

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

Given 9 parameters and no output schema, the description is minimal. It omits return format and variable details, but the schema provides parameter descriptions. It is adequate for selection but not for full operational 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 description coverage is high (78%), so the input schema already explains most parameters. The description mentions 'hourly or daily' which maps to two parameters but adds no new meaning beyond the schema's existing descriptions.

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

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

The description clearly states it provides 'weather forecast up to 16 days, hourly or daily,' specifying a verb (forecast) and resource (weather data) with concrete time and granularity limits. This differentiates it from siblings like 'historical' or 'marine' which cover different domains.

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

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

No guidance on when to use this tool versus alternatives such as 'historical' or 'marine'. The description does not mention when not to use it or provide context for selection among related weather tools.

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

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

The description correctly indicates the tool is destructive (deletes a memory). However, it lacks details such as whether the deletion is permanent, if it affects only the current agent's memories, or any confirmation requirements. With no annotations provided, the description carries the full burden but remains minimal.

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

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

The description is extremely concise: two sentences—first stating purpose, second providing usage guidelines. Every sentence is necessary and adds value, with no superfluous words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It covers purpose and usage guidelines. However, it omits behavioral details like permanence or side effects, which would make it fully 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?

The input schema already describes the single parameter 'key' as 'Memory key to delete', and the description does not add significant meaning beyond that. Schema coverage is 100%, so a baseline of 3 is appropriate. No additional format or sourcing guidance is given.

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

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

The description explicitly states the verb 'Delete' and the resource 'previously stored memory by key', making the tool's purpose very clear. It also distinguishes itself from sibling tools by pairing with 'remember' and 'recall', which handle other memory operations.

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: when context is stale, the task is done, or to clear sensitive data. It also suggests pairing with 'remember' and 'recall', implicitly advising against using it when those are more appropriate.

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

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

With no annotations provided, the description must disclose behavioral traits but only states a basic function. It does not mention performance characteristics, accuracy, rate limits, or side effects, which is insufficient for an agent to gauge behavior.

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

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

The description is a single concise sentence, well front-loaded with the essential action. It is efficient but could be slightly more informative without losing brevity, hence not a perfect 5.

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

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

The tool has no output schema and lacks description of return values or behavior. It also omits elaboration on parameters like count and language. For a simple geocoding tool, important context (e.g., result format, coordinate system) is missing.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds no extra meaning beyond the schema; it simply restates the action. Schema already explains parameters adequately.

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

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

The description clearly states the verb 'resolve' and the resource 'place name to coordinates', making the purpose immediately understandable. It distinguishes from sibling tools like weather or entity tools, though a sibling 'resolve_entity' exists but has a different focus.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'resolve_entity' or other data lookup tools. The description does not mention context like input types or result limitations, leaving the agent without usage boundaries.

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 must fully convey behavioral traits. It mentions the time range and date requirement but omits any side effects, safety information, or return behavior. The tool likely performs a read-only data retrieval, but this is not stated.

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 one sentence, concise and front-loaded with the essential information. It could be slightly more descriptive without becoming verbose, but it is efficient for a minimal viable description.

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 7 parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain the output format, how to select between daily and hourly data, or the coordinate system for latitude/longitude. An agent would need to infer too much from the parameter names alone.

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

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

The schema description coverage is only 29%, and the description adds no extra parameter information beyond reinforcing the need for start and end dates. It does not explain the meaning or usage of parameters like 'daily', 'hourly', 'timezone', 'latitude', or 'longitude'.

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

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

The description states it provides ERA5 reanalysis data from 1940 to present, which clearly identifies the historical weather data source and distinguishes it from sibling tools like 'forecast' and 'marine'. The verb is implied but specific enough for an agent to understand the tool's purpose.

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

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

No guidance is given on when to use this tool over other weather-related siblings (e.g., 'forecast', 'marine', 'flood'). The only hint is that a date range is required, but no explicit when-to-use or when-not-to-use 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 must carry behavioral disclosure. It indicates a read-only forecast, but lacks details on side effects, rate limits, or authentication needs. Minimal transparency beyond the implied nature.

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

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

The description is very concise (one sentence) but borderline under-specified. While front-loaded, it could benefit from slightly more detail without losing brevity.

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 few annotations, the description is too brief. It omits return format, units, and how parameters affect results, leaving an agent with insufficient 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 description coverage is only 25% (hourly parameter). The description does not explain the meaning or usage of latitude, longitude, or forecast_days, failing to compensate for the low 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 provides wave height, period, and direction for a forecast, distinguishing it from sibling tools like air_quality or flood. However, it does not explicitly mention the location-based nature, which is evident from the schema but not reinforced.

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

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

No guidance is given on when to use this tool versus alternatives like the 'forecast' sibling. There is no mention of prerequisites, limitations, or 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?

Despite no annotations, the description discloses key behaviors: rate-limited, team reads digests daily, signal affects roadmap, doesn't count against quota. Minor missing info like whether feedback is editable or public, but sufficient for a feedback 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?

Well-structured single paragraph covering all necessary points. Slightly verbose with rate limit repetition ('Free; doesn't count against your tool-call quota' could be merged), but overall effective.

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

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

Given 3 parameters, nested object, and no output schema, the description explains when to use, what to include, constraints, and how feedback is processed. Missing output info is acceptable since feedback is a one-way action.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema: explains enum values with concrete examples, advises not to paste end-user prompt, and describes optional context structure. Thorough 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?

Description clearly states the tool is for providing feedback (bug, feature, data_gap, praise) to the Pipeworx team. It distinguishes itself from sibling tools, which are all data-oriented, making this the only feedback 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?

Explicitly tells when to use: for bugs, missing features, data gaps, or praise. Provides specific scenarios and also notes rate limits (5 per identifier per day) and that it's free and doesn't count against tool-call 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?

No annotations provided, so description carries full burden. It discloses retrieval/list behavior, scoping, and pairing with remember/forget. Could mention behavior on missing key or listing format, 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?

Two concise sentences with front-loaded purpose. No redundant or 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?

Given the tool's simplicity (one optional param, no output schema), the description fully covers purpose, usage, and relationships to sibling tools. No gaps identified.

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

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

Schema coverage is 100% with a clear parameter description. The description reinforces the parameter's role and adds context about scoping and listing behavior, providing 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?

Clearly states the tool's action (retrieve/list), resource (values saved via remember), and distinguishes from siblings like remember and forget. The description explicitly defines the dual behavior with and without the key argument.

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 concrete examples of use cases (target ticker, address, research notes) and explains scope (by identifier). Does not explicitly list when not to use, but the context is clear enough for agent 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?

No annotations provided, so description carries full burden. It discloses parallel fan-out to three sources and return structure, but lacks details on rate limits, authentication, 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?

Description is concise (about 80 words) and well-structured: purpose, example queries, behavior, parameter details. 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?

Covers all parameters, fan-out behavior, and return format. Missing context on potential errors, rate limits, or authentication requirements, but overall adequate for a read tool.

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

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

Schema coverage is 100%, but description adds value by explaining the 'since' parameter accepts ISO dates or relative shorthands with examples, and clarifies 'value' as ticker or CIK.

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

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

The description clearly states the tool's purpose: 'What's new with a company in the last N days/months?' and lists example queries. It specifies fan-out to multiple sources, distinguishing it from sibling tools like entity_profile and compare_entities.

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

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

Provides explicit example queries and states 'Use when a user asks...' or monitoring for changes. However, it does not explicitly mention when not to use or list 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 provided, but description discloses key behavioral traits: scoped by identifier, persistence differences for authenticated vs. anonymous sessions, and pairing with recall/forget.

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 three concise sentences: first states core purpose, second gives usage context with examples, third adds technical details. 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 tool's simplicity (2 required params) and no annotations or output schema, the description covers purpose, usage, behavior, and parameter hints. Missing error handling, but sufficient for typical 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%, so baseline is 3. Description adds example keys but no further technical details 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 saves data for later reuse, with specific verb and resource. It distinguishes from sibling tools like 'recall' and 'forget' by mentioning them explicitly.

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 guidance with examples (resolved ticker, user preference). Doesn't explicitly state when not to use, but context is clear enough.

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 exist, so the description is the sole source. It states what the tool returns (IDs + pipeworx:// citation URIs) but lacks disclosure of side effects, required permissions, network calls, or error handling. 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?

Three sentences, front-loaded with purpose, followed by usage and examples. No redundancy; every sentence provides necessary information. Highly efficient.

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

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

Given no output schema, the description explains return values (IDs, citation URIs) and provides concrete examples. It also notes the tool replaces multiple lookups. Missing details on failure modes or edge cases, but sufficient 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 coverage is 100% with descriptions for both params. The description adds significant value with examples of valid values (e.g., 'AAPL', '0000320193', 'ozempic') and clarifies the 'value' parameter's flexibility, going 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 resolves canonical identifiers (CIK, ticker, RxCUI, LEI) for companies and drugs, using specific verbs like 'look up' and 'returns'. It distinguishes from siblings by positioning itself as a prerequisite step before other identifier-requiring 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 instructs to use 'before calling other tools that need official identifiers', provides concrete examples (Apple → AAPL, Ozempic → RxCUI 1991306), and mentions it replaces 2–3 lookup calls, giving clear when-to-use guidance.

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

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

Since no annotations are provided, the description carries full burden. It discloses the verdict types, citation format, and domain limitation (v1, company-financial). However, it does not explicitly state read-only or non-destructive nature.

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 purpose, then usage, then capabilities, then return details. Every sentence adds value, with no redundancy.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers domain, input format, return structure, and rationale, making it fully informative for an agent.

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

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

Schema coverage is 100% for the single required parameter. The description adds concrete examples and clarifies the natural-language format, going beyond the schema's minimal description.

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

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

The description clearly states the tool fact-checks or verifies factual claims against authoritative sources, specifying it handles company-financial claims via SEC EDGAR + XBRL. This distinct action sets it apart from sibling tools like compare_entities or 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?

Provides explicit usage examples (e.g., 'Is it true that...?') and notes it replaces multiple sequential calls, but does not mention when not to use it or alternative tools for out-of-scope claims.

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