swapi

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it picks the right tool, fills arguments automatically, and returns results. However, it lacks details on limitations such as rate limits, error handling, or data source constraints, which would be beneficial for full 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 appropriately sized and front-loaded, starting with the core functionality and followed by supportive examples. Every sentence earns its place by clarifying the tool's ease of use and providing illustrative cases without unnecessary elaboration.

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 (natural language processing to select tools) and lack of annotations or output schema, the description is mostly complete by explaining the process and examples. However, it could improve by mentioning potential limitations or the types of data sources, but it adequately covers the essential 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?

The schema description coverage is 100%, so the input schema already documents the single parameter 'question' with a clear description. The description adds minimal value beyond this by rephrasing it as 'Your question or request in natural language', but doesn't provide additional syntax, format, or constraints, meeting 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 clearly states the tool's purpose with specific verbs ('Ask a question', 'get an answer') and resources ('best available data source'), and distinguishes it from siblings by emphasizing natural language interaction without needing to browse tools or learn schemas. It provides concrete examples that illustrate its unique function compared to more specific sibling tools like get_film or get_planet.

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 ('just describe what you need' in plain English) and when not to use alternatives ('No need to browse tools or learn schemas'), providing clear context and exclusions. It contrasts with sibling tools that likely require specific parameters or schemas, making the guidance comprehensive.

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 mentions returning 'paired data + pipeworx:// resource URIs' but does not disclose whether the tool is read-only, requires authentication, or has rate limits. Some behavioral context is added beyond the schema, but it's incomplete.

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

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

The description is three sentences, front-loaded with the core purpose. Every sentence adds value without redundancy or unnecessary detail.

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

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

With no output schema, the description explains return values for each type in moderate detail. It covers key fields but lacks specifics on data format or pagination. Given the tool's moderate complexity, it is sufficiently complete.

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

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

Schema description coverage is 100%, providing good baseline. The description adds meaning by detailing the specific fields returned for each type (e.g., revenue, net income for companies; adverse-event count for drugs), which goes beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's function: comparing 2-5 entities side by side in one call. It specifies what each type (company/drug) returns, and distinguishes from sibling tools that retrieve single entities (e.g., get_film, get_planet).

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 when to use this tool by noting it replaces 8-15 sequential agent calls, implying efficiency for multi-entity comparisons. It does not explicitly state when not to use or list alternatives, but the context is clear given sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a search operation that returns relevant tools based on natural language queries, with implied read-only functionality. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions.

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 perfectly concise and front-loaded with two sentences that each earn their place. The first sentence explains the core functionality, and the second provides crucial usage guidance. There's zero wasted text or 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 moderate complexity (search functionality with 2 parameters) and lack of annotations/output schema, the description provides good context about when and why to use it. However, it doesn't describe the return format or what 'most relevant' means algorithmically, leaving some gaps in understanding the tool's complete behavior.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema - it mentions the query concept but provides no extra details about parameter usage, constraints, or interactions.

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 with specific verbs ('search', 'returns') and resources ('Pipeworx tool catalog', 'most relevant tools with names and descriptions'). It distinguishes from siblings by focusing on tool discovery rather than specific data retrieval like 'get_film' or 'search_people'.

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

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

The description provides explicit usage guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear context for when to use this tool versus alternatives, including a quantitative threshold (500+ tools) and strategic positioning (first step in tool discovery).

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 aggregates data from multiple sources (SEC, XBRL, USPTO, GDELT, GLEIF) and returns citation URIs. However, it does not mention output size, pagination, or potential rate limits, which are minor omissions for a read-only profile 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?

Three sentences effectively convey purpose, included data, and an exception. Front-loaded with the key benefit ('Full profile... in one call'). No wasted words; list of data types is compact 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?

Given no output schema, description covers what data is returned (list of data types and citation URIs). It also notes an alternative for federal contracts. Could mention limits or pagination behavior, but overall it is adequate 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?

Input schema has 100% coverage, and description adds significant context: explains that 'type' currently only supports 'company' with future plans, and for 'value' clarifies accepted formats (ticker or CIK) and warns against providing names directly, directing to resolve_entity. This goes 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?

Clearly states the tool retrieves a full profile of an entity across multiple packs, lists included data types (SEC filings, XBRL, patents, news, LEI), and contrasts with the sibling usa_recipient_profile. The verb 'get full profile' and specific resources are well-defined.

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

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

Explicitly advises against using this tool for federal contracts, directing to usa_recipient_profile. Also notes that names are not supported in the 'value' parameter, recommending resolve_entity first. Provides clear when-to-use and when-not-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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete' which implies a destructive mutation, but doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., on related data). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, clear sentence with zero waste. It's front-loaded with the core action ('Delete') and resource ('a stored memory'), making it efficient and easy to parse. Every word earns its place.

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

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

Given the tool's destructive nature (implied by 'Delete'), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't address behavioral aspects like permanence, permissions, or error handling, nor does it explain what happens upon success (e.g., confirmation message). For a mutation tool, this leaves critical 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?

The input schema has 100% description coverage, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond this, such as key format, examples, or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('Delete') and the resource ('a stored memory by key'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'recall' (which likely retrieves memories) or 'remember' (which likely stores memories), though the verb 'Delete' strongly implies a destructive operation distinct from those.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a memory must exist to delete it), exclusions (e.g., not for bulk deletion), or refer to sibling tools like 'recall' or 'remember' for context. Usage is implied only by the action itself.

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 describes the return data (title, episode number, etc.) but does not disclose behavioral traits such as error handling (e.g., what happens if an invalid ID is provided), rate limits, authentication needs, or whether it's a read-only operation. The description adds some context but leaves significant gaps in behavioral 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 a single, well-structured sentence that efficiently conveys the tool's purpose, input method, and return data. It is front-loaded with the core action and includes no unnecessary details, making it highly concise and easy to understand.

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 low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and return fields but lacks details on error cases, behavioral constraints, or usage nuances. Without annotations or an output schema, more context on what to expect in responses or failures 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?

The input schema has 100% description coverage, with the 'id' parameter documented as 'Film ID (e.g., 1 for A New Hope)'. The description adds no additional parameter semantics beyond what the schema provides, such as valid ID ranges or format details. With high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

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 specific action ('Get a Star Wars film') and resource ('by its numeric ID'), distinguishing it from sibling tools like get_planet or get_starship. It explicitly identifies the domain (Star Wars films) and the retrieval mechanism (numeric ID), making the purpose unambiguous and distinct.

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 by specifying 'by its numeric ID' and listing return fields, but it does not explicitly state when to use this tool versus alternatives like search_people. It provides context for retrieving specific films but lacks guidance on exclusions or direct comparisons 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns specific data fields, which is helpful, but doesn't cover critical aspects like error handling (e.g., what happens if the ID is invalid), rate limits, authentication needs, or whether it's a read-only operation. The description adds some context but leaves significant gaps for a tool with no 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 appropriately sized and front-loaded: it starts with the core action ('Get a Star Wars planet by its numeric ID') and follows with return details in a single, efficient sentence. Every part earns its place without redundancy or 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 tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does and what it returns, which is adequate for a simple lookup. However, without annotations or output schema, it should ideally cover more behavioral aspects like error cases or data freshness to be fully helpful.

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%, with the parameter 'id' fully documented in the schema as 'Planet ID (e.g., 1 for Tatooine)'. The description adds no additional parameter information beyond what the schema provides, such as format constraints or examples. Baseline 3 is appropriate since the schema handles the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Get a Star Wars planet by its numeric ID' specifies the verb ('Get') and resource ('Star Wars planet'), and 'Returns name, climate, terrain, population, and orbital data' details the output. It distinguishes from siblings like 'get_film' or 'get_starship' by focusing on planets, but doesn't explicitly differentiate beyond that.

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. The description mentions retrieving a planet by ID but doesn't clarify if this is for specific lookups versus broader searches (e.g., compared to 'search_people'), or any prerequisites like ID availability. It lacks explicit when/when-not statements or named 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?

With no annotations provided, the description carries full burden. It discloses the return data structure (name, model, manufacturer, etc.), which is valuable behavioral information. However, it doesn't mention error handling, rate limits, authentication needs, or whether the operation is idempotent - gaps for a tool with zero annotation coverage.

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 tightly constructed sentences with zero waste. The first sentence establishes purpose and input, the second specifies outputs. Every word serves a clear function, and information is front-loaded appropriately for quick comprehension.

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 read operation with 100% schema coverage but no output schema or annotations, the description provides adequate coverage of purpose and return values. However, it lacks behavioral details like error conditions or performance characteristics that would be helpful given the absence of structured metadata.

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% with the single parameter well-documented, so baseline would be 3. The description adds value by contextualizing the ID parameter with 'Starship ID' and providing an example ('e.g., 9 for the Death Star'), though this example is also in the schema. It earns a 4 for reinforcing and slightly expanding on schema information.

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

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

The description clearly states the specific action ('Get a Star Wars starship'), identifies the resource ('by its numeric ID'), and distinguishes from siblings by focusing on starships rather than films, planets, or people. It uses precise language that leaves no ambiguity about the tool's function.

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

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

The description implies usage context by specifying 'by its numeric ID' and listing return fields, but provides no explicit guidance on when to use this tool versus alternatives like search_people for broader queries. It doesn't mention prerequisites or exclusions, leaving usage decisions to inference.

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 the rate limit and implies a write operation (sending feedback). However, it does not detail what happens after sending (e.g., storage, retrieval) or behavior when rate limit is exceeded. Given the simplicity of the tool, this is 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?

The description is concise, consisting of four sentences that efficiently convey purpose, use cases, content guidelines, and rate limits. Information is front-loaded, with no superfluous text. Every sentence earns its place.

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

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

For a simple feedback tool with a well-documented schema, the description covers purpose, usage, content rules, and rate limits. It does not explain the return value (acknowledgment), but that is generally understood. The nested context parameter is documented in the schema. Overall, it provides sufficient information 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?

The input schema has 100% description coverage, clearly documenting each parameter. The description adds value beyond the schema by instructing users on message content: 'Describe what you tried... do not include the end-user's prompt verbatim.' This provides critical usage context for the message parameter.

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

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

The description clearly states 'Send feedback to the Pipeworx team' and enumerates specific use cases (bug reports, feature requests, missing data, praise). It effectively distinguishes this tool from siblings, which serve different purposes like asking questions or retrieving data.

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

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

The description explicitly states when to use the tool (for feedback types) and provides important usage instructions: 'Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim.' It also mentions the rate limit of 5 messages per day, guiding frequency. It does not explicitly exclude other uses, but the use cases are well-defined.

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 and does well by explaining the dual behavior (retrieve by key or list all). It clarifies persistence across sessions and mentions the optional parameter behavior. However, it doesn't disclose potential limitations like maximum memory size, retrieval time, or error conditions.

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 perfectly concise with two sentences that each earn their place. The first sentence explains the dual functionality, and the second provides usage context. No wasted words, and information is front-loaded appropriately.

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

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

For a simple retrieval tool with 1 optional parameter and no annotations/output schema, the description covers purpose, usage, and parameter semantics well. However, it doesn't describe the return format (what a 'memory' contains) or potential error cases, leaving some gaps 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining the semantic effect of omitting the key parameter ('omit to list all keys'), which goes beyond the schema's technical description. This provides valuable guidance for parameter 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's purpose with specific verbs ('retrieve', 'list') and resources ('previously stored memory by key', 'all stored memories'). It distinguishes from siblings like 'remember' (store) and 'forget' (delete) by focusing on retrieval 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 this tool: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter ('omit key to list all keys'), giving clear operational instructions.

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 fully carries the behavioral transparency burden. It discloses the parallel fan-out to SEC EDGAR, GDELT, and USPTO, the return format (structured changes + total_changes count + pipeworx:// URIs), and input format constraints. No contradictions with annotations exist.

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

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

The description is four sentences, each providing direct value. It is front-loaded with the purpose, followed by details on behavior, input formats, and output. No superfluous words; every sentence earns its place.

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

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

Given the complexity (3 parameters, no output schema), the description is highly complete. It covers input constraints, behavior, and return structure. A minor gap: it does not describe error behavior (e.g., if entity not found), but overall it provides sufficient context 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 description coverage is 100%, and the description adds significant meaning beyond the schema: it explains the fan-out behavior, accepted formats for 'since' (ISO date or relative), examples, and the single supported entity type. This enriches the agent's understanding beyond basic parameter 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: 'What's new about an entity since a given point in time.' It uses a specific verb ('brief me') and resource ('changes'), and distinguishes from siblings like 'entity_profile' and 'compare_entities' by detailing the fan-out to multiple 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?

The description provides explicit use cases: 'Use for "brief me on what happened with X" or change-monitoring workflows.' It implies appropriate contexts but does not explicitly state when not to use the tool or list alternatives. The constraint that only 'company' type is supported is noted.

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 of behavioral disclosure. It clearly describes the storage behavior, persistence characteristics based on authentication status, and session duration limits. However, it doesn't mention potential limitations like storage size constraints, key collision behavior, or error conditions, leaving some behavioral aspects unspecified.

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 perfectly front-loaded with the core purpose in the first sentence, followed by usage guidance and behavioral details. Every sentence adds essential information without redundancy or unnecessary elaboration. The two-sentence structure is efficient and zero-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?

For a simple storage tool with no annotations and no output schema, the description provides excellent context about what it does, when to use it, and persistence behavior. The main gap is the lack of information about return values or confirmation of successful storage, but given the tool's straightforward nature, the description is largely 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 description coverage is 100%, providing complete documentation of both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (key examples and value content types are already covered). This meets the baseline expectation when schema coverage is comprehensive.

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 specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'forget' (deletion) and 'recall' (retrieval). It provides concrete examples of what to store ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous and differentiated.

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 save intermediate findings, user preferences, or context across tool calls') and provides critical context about persistence differences ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which helps the agent decide when this tool is appropriate versus alternatives like using external storage or not storing at all.

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 explains the single-call nature, supported type, and return fields, but lacks details on error behavior, state modification (likely read-only but not stated), or rate limits.

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 plus a concise list of return fields. Front-loaded with purpose, every sentence adds value, no redundancy.

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

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

No output schema, but description explains return values (ticker, CIK, name, URIs). Covers primary use case, but could detail output structure or error handling for completeness.

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

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

Schema coverage is 100%, and description adds value with example inputs (AAPL, CIK, name) and clarification of the 'value' parameter's flexibility, going beyond the schema's enum and 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?

Description clearly states it resolves entities to canonical IDs, specifies v1 supports 'company' type, lists accepted inputs (ticker, CIK, name), and mentions replacing 2-3 lookup calls, differentiating from alternatives.

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?

Description implies when to use by stating it replaces multiple lookup calls, but does not explicitly exclude cases or compare to sibling tools. Sibling tools are unrelated, so no direct competition.

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 of behavioral disclosure. It mentions the return fields (name, attributes, etc.) but doesn't cover critical aspects like error handling, rate limits, authentication needs, or whether it's a read-only operation. For a search tool with zero annotation coverage, this leaves significant gaps.

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 and front-loaded: one sentence states the purpose and another lists return fields. Every word earns its place with zero waste, making it easy for an AI agent to parse quickly.

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

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

Given the simple single-parameter schema and no output schema, the description is minimally adequate. It covers the purpose and return fields, but lacks behavioral context (e.g., search behavior, errors) that would be helpful for an agent. Without annotations, it should do more to compensate.

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, with the 'query' parameter well-documented. The description adds no additional parameter semantics beyond what the schema provides (e.g., no details on search syntax, partial matches, or case sensitivity). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: searching Star Wars characters by name. It specifies the verb 'search' and resource 'Star Wars characters', making it distinct from sibling tools like get_film or get_planet. However, it doesn't explicitly differentiate from potential sibling search tools (none listed), so it's not a perfect 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, limitations, or compare it to sibling tools like get_film. Usage is implied by the purpose, but no explicit when/when-not instructions are 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?

With no annotations, the description carries the full burden. It discloses the data sources (SEC EDGAR, XBRL), the output format (verdict types, extracted value, citation, percent delta), and the scope limitation (v1 supports only specific claim types). It does not address error behavior, rate limits, or required authentication, but it provides sufficient behavioral context for typical usage.

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 (4 sentences) and front-loaded with the core purpose. Each sentence adds value: purpose, scope, output details, and comparative advantage. There is no redundancy or extraneous text.

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

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

Given the single input parameter, no output schema, and no annotations, the description provides a comprehensive view: input format with examples, supported claim types, data sources, output structure including citation format, and a note on its efficiency advantage over sequential agent calls. It covers all essential aspects an agent needs 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% (the single 'claim' parameter has a description with examples). The tool description adds context about the domain and examples, but does not significantly extend the parameter meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter 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 tool's purpose: fact-checking natural-language claims against authoritative sources. It specifies the domain (company-financial claims for US public companies) and lists the verdict types and output elements (verdict, structured form, actual value, citation, delta). It differentiates itself from siblings by noting it replaces 4-6 sequential agent calls, indicating a composite, higher-level function.

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

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

The description explicitly limits use to company-financial claims (revenue, net income, cash) for public US companies, providing clear context. It implies when to use this tool (for such claims) and mentions it consolidates multiple steps. It does not explicitly state when not to use or list alternative tools, but the domain restriction serves as a guideline.

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