poetry

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a query tool that interprets natural language, selects appropriate data sources, and returns results. However, it lacks details on limitations (e.g., rate limits, error handling, or specific data source constraints), which prevents a perfect score.

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

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

The description is front-loaded with the core functionality, followed by supportive details and examples. Every sentence earns its place: the first explains the purpose, the second clarifies the mechanism, and the third provides concrete use cases. It's efficiently structured 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 (natural language processing to select tools) and lack of annotations/output schema, the description does well by explaining the process and providing examples. However, it could be more complete by mentioning potential limitations or the types of data sources available, which would help an agent anticipate edge cases.

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

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

The input schema has 100% coverage, so the baseline is 3. The description adds value by emphasizing the natural language aspect ('plain English', 'describe what you need') and providing examples that illustrate the expected format and scope of the 'question' parameter, going beyond the schema's basic 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's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'). It distinguishes from siblings by emphasizing natural language input versus structured tool selection.

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: 'No need to browse tools or learn schemas — just describe what you need.' It provides clear alternatives (implicitly, use other tools for structured operations) and includes three concrete examples to illustrate appropriate use cases, making it highly actionable for an AI agent.

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

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

With no annotations, the description carries the full burden. It discloses the types of data returned and the entity types supported, but does not mention any behavioral traits such as error handling, rate limits, or being a read-only operation.

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

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

The description is three sentences with no wasted words: the first sentence states the core functionality, the second and third provide entity-specific details. It is front-loaded and efficient.

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

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

Given no output schema, the description mentions the return format (paired data + URIs). It covers input constraints (2–5 entities) and data sources. It could be more complete by mentioning error handling, but overall it gives sufficient context for the 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 already has 100% description coverage, but the description adds valuable context beyond the schema: it details the exact metrics returned for each entity type (revenue, net income, etc. for companies; adverse event counts for drugs). This helps the agent understand what the comparison entails.

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

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

The description clearly states that the tool compares 2–5 entities side by side in one call, and specifies exactly what data is compared for each entity type (company financials from SEC EDGAR, drug metrics from FDA). This is distinct from all sibling tools, which are unrelated to comparison.

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 efficiency by stating it replaces 8–15 sequential agent calls, but does not explicitly state when to use it versus alternatives (e.g., resolve_entity for single lookups) 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the search functionality and when to call it, but doesn't describe rate limits, authentication needs, error conditions, or response format details. It adds some context about being a 'first' call for large catalogs, but lacks comprehensive behavioral traits.

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 core function, and the second provides crucial usage guidance. No wasted words, and the most important information ('Call this FIRST') is appropriately front-loaded.

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

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

Given the tool's moderate complexity (search functionality with 2 parameters) and no output schema, the description is reasonably complete. It explains the purpose, when to use it, and what it returns. However, without annotations or output schema, it could benefit from more detail about response structure or error handling for full 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 schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the general purpose ('search by describing what you need') but provides no additional syntax, format, or semantic details about the parameters.

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 the Pipeworx tool catalog') and resource ('tool catalog'), distinguishing it from sibling poetry tools. It explicitly mentions what it returns ('most relevant tools with names and descriptions'), making the function unambiguous.

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

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

The description provides explicit usage guidelines: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear conditions for when to use this tool versus alternatives, including a quantitative threshold and specific scenario.

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 what data is returned and that URIs are provided. While it implies a read-only query, it does not explicitly state side effects or authorization needs. Still quite transparent.

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

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

Concise and well-structured: first sentence states core purpose, then lists contents, mentions URIs, and provides usage alternatives. No redundant 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 no output schema and only two parameters, the description covers purpose, input constraints, output format (URIs), and alternatives. Missing explicit output structure but sufficient for agent 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?

Input schema has 100% coverage with good descriptions. The description adds value by detailing what the 'company' type returns, explaining the tool's behavior beyond schema definitions.

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

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

The description clearly states the tool's purpose: retrieving a full entity profile across multiple data sources in one call, listing specific data types for companies. It distinguishes itself by noting an alternative for federal contracts.

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 guidance: replaces 10-15 sequential calls, suggests using usa_recipient_profile for federal contracts, and advises using resolve_entity for name-based queries. Clearly defines when and when not to use.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects. It lacks crucial context about what 'stored memory' means in this system.

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

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and gets straight to the point without unnecessary elaboration. Every word earns its place in conveying the essential function.

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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a 'stored memory' in this context, what happens after deletion, whether there are confirmation steps, or what the response looks like. The agent lacks crucial 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 100%, so the schema already documents the single 'key' parameter adequately. The description adds minimal value beyond what the schema provides, merely restating that it's for deleting by key. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Delete') and target resource ('a stored memory by key'), distinguishing it from sibling tools like 'recall' (likely retrieve) and 'remember' (likely store). It provides a precise verb+resource combination 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 provides no guidance on when to use this tool versus alternatives like 'recall' (which likely retrieves memories) or other memory-related operations. It doesn't mention prerequisites, consequences, or appropriate contexts for deletion versus other memory management operations.

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 description carries full burden. Discloses rate limiting (5 messages per identifier per day) and content restrictions (no end-user prompt verbatim, describe in terms of Pipeworx tools/data). These are critical behavioral traits not inferrable from the schema.

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

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

Three sentences with no waste. First sentence states purpose. Second adds usage and content rules. Third covers rate limiting and a positive note ('Free'). Information is front-loaded and 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?

Tool is simple (3 params, nested object, no output schema). Description covers purpose, usage, content constraints, and rate limiting. No output schema needed as feedback is sent without a meaningful return value. Complete for an agent to use correctly.

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

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

Schema description coverage is 100% and includes good descriptions for type, context, and message. The description adds minimal extra meaning beyond reinforcing enum values and a suggestion for message content (not to include prompt). Baseline 3 is appropriate.

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

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

Description clearly states 'Send feedback to the Pipeworx team' and enumerates use cases (bug reports, feature requests, missing data, praise). It distinguishes itself from sibling tools, none of which serve a feedback 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?

Explicitly states when to use the tool (bug reports, feature requests, etc.) and provides content guidance ('describe what you tried... do not include prompt verbatim'). Lacks explicit when-not or alternative tools, but siblings are unrelated enough that it's not a gap.

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

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

No annotations are provided, so the description carries the full burden. It mentions the return format ('poem titles and full text'), which adds some behavioral context, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is two sentences, front-loaded with the core purpose and followed by return details. Every sentence adds value without redundancy, making it appropriately sized 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 low complexity (1 parameter, no output schema, no annotations), the description covers the basic purpose and return format adequately. However, it lacks behavioral details like error cases or limitations, which would be helpful for a tool with no annotations or output schema.

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%, with the parameter 'author' well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. 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 verb ('Get') and resource ('all poems by a specific author'), specifying both the action and target. It distinguishes from siblings by focusing on author-based retrieval rather than random selection (random_poems) or general search (search_poems).

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 a specific author,' which helps differentiate it from random_poems (no author filter) and search_poems (broader search). However, it doesn't explicitly state when NOT to use this tool or name alternatives, missing full explicit 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving 'one or more random poems' but fails to describe key traits like whether this is a read-only operation, potential rate limits, or how randomness is implemented (e.g., uniform distribution, seed-based). This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand 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 tool's low complexity (one optional parameter) and lack of output schema, the description is minimally adequate but incomplete. It covers the basic purpose but omits details on output format (e.g., structure of returned poems) and behavioral aspects, which are important for a tool with no annotations to guide the 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%, with the parameter 'count' fully documented in the input schema. The description adds no additional semantic context beyond implying multiplicity ('one or more'), which aligns with the schema but doesn't provide extra value. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Get') and resource ('random poems from the collection'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'poems_by_author' or 'search_poems' beyond the 'random' aspect, which is why it doesn't reach a perfect score.

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 like 'poems_by_author' or 'search_poems'. It lacks context such as use cases for random poems versus author-specific or search-based retrieval, leaving the agent without explicit usage direction.

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 that memories can be retrieved from current or previous sessions, implying persistence across sessions. However, it doesn't detail error handling (e.g., if key doesn't exist), performance characteristics, or data format of retrieved memories, leaving gaps in behavioral understanding.

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

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

The description is efficiently structured in two sentences: the first states the core functionality with parameter nuance, and the second provides usage context. Every phrase adds value without redundancy, making it appropriately concise and front-loaded.

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

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

Given no annotations and no output schema, the description adequately covers the tool's purpose and basic usage. However, it lacks details on return values (e.g., format of retrieved memories or list output), error conditions, or session persistence mechanics, which are important for a tool with potential cross-session data access.

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 'key' fully documented in the schema. The description adds marginal value by clarifying that omitting the key lists all memories, which is implied but not explicitly stated in the schema's 'omit to list all keys' note. This aligns with the baseline score when schema coverage is high.

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: 'Retrieve a previously stored memory by key, or list all stored memories (omit key).' It specifies the verb ('retrieve'/'list') and resource ('memory'), though it doesn't explicitly differentiate from sibling tools like 'remember' or 'forget' beyond the retrieval vs. storage distinction.

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

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

The description provides clear context for when to use the tool: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It explains the optional parameter behavior (omit key to list all), but doesn't explicitly state when not to use it or name alternatives among siblings.

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

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

With no annotations, the description carries full burden. It discloses the parallel fan-out behavior, accepted since formats, and return structure (structured changes, count, URIs). It does not mention error handling or limitations beyond type, but the disclosure is good.

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

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

Four sentences, front-loaded with purpose. Each sentence adds essential information: purpose, behavior, parameter format, return and use cases. No wasted words 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 complexity (fan-out to multiple sources) and no output schema, the description covers the essential aspects: entity type, time specification, return fields, and typical usage. It omits edge cases (e.g., error handling, time range limits) but suffices for common monitoring workflows.

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 3. The description adds value by explaining the effect of type (fan-out), providing guidance on since format ('Use "30d" or "1m" for typical monitoring'), and clarifying the value parameter (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 about an entity since a given point in time.' It specifies the behavior for company type (fan-out to SEC, GDELT, USPTO), the return format, and provides use cases. This differentiates it from siblings 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?

The description explicitly suggests use cases: 'Use for "brief me on what happened with X" or change-monitoring workflows.' It implies when to use but does not explicitly state when not to use or name 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 the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool performs a write operation ('store'), specifies persistence characteristics ('authenticated users get persistent memory; anonymous sessions last 24 hours'), and implies it's for session-scoped data. However, it doesn't mention potential limitations like storage limits 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 appropriately sized and front-loaded: the first sentence states the core purpose, and subsequent sentences add essential context without redundancy. Every sentence earns its place by providing valuable information about usage, persistence, and authentication differences.

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 (write operation with persistence nuances), no annotations, and no output schema, the description is reasonably complete. It covers purpose, usage context, and behavioral aspects like persistence rules. However, it doesn't describe what happens on success/failure or potential error cases, leaving some gaps for a mutation tool.

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

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

The schema description coverage is 100%, so the schema already fully documents both parameters (key and value). The description adds no additional parameter-specific information beyond what's in the schema. It mentions general use cases ('findings, addresses, preferences, notes') but doesn't clarify parameter semantics beyond the schema's 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 purpose with specific verbs ('store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'recall' (which retrieves) and 'forget' (which removes). It explicitly mentions what gets stored ('intermediate findings, user preferences, or context across tool calls'), making the purpose unambiguous.

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

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

The description provides clear context on when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but does not explicitly state when not to use it or name alternatives. It implies usage for persistence needs but lacks explicit exclusions or comparisons with other memory-related tools like 'recall' or 'forget'.

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 that the tool returns ticker, CIK, company name, and pipeworx:// URIs, and that it performs a single call. However, it does not mention error handling, permissions, or limitations beyond type support. For a resolution tool, this is adequate but could be more transparent.

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

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

The description is two sentences long, with the first stating the primary purpose and the second covering version, input formats, output, and benefit. It is front-loaded, concise, and contains no extraneous information.

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

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

Given the low complexity (2 simple params, no nested objects, no output schema) and 100% schema coverage, the description provides sufficient context: input formats, output fields, and the benefit of replacing multiple calls. It could mention error handling or exact matching requirements, but it is largely complete for an agent to use effectively.

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

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

Schema coverage is 100%, so the schema already describes both parameters well. The description adds value by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and explaining the allowed input formats. This goes beyond the schema's descriptions, making parameter usage clearer.

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 an entity to canonical IDs across Pipeworx data sources. It specifies the supported type (company) and input formats (ticker, CIK, name). It distinguishes itself from sibling tools, which are mostly about poems/memory, by focusing on entity resolution and data lookup.

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 that the tool replaces 2–3 lookup calls, implying efficiency and suggesting when to use it. It also notes that v1 only supports type 'company', setting expectations. However, it does not explicitly state when not to use it or mention alternatives among siblings, though none directly compete.

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 mentions the return format ('matching poems with their full text'), which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or search behavior (e.g., partial matches, case sensitivity), leaving significant gaps for a search tool.

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

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

The description is highly concise and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second clarifies the return value, making it efficient and easy to parse.

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

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

Given the tool's low complexity (1 parameter, no nested objects) and no output schema, the description is minimally adequate. It covers purpose and return format but lacks behavioral details like search scope or error cases. Without annotations, it should provide more context 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 description coverage is 100%, with the parameter 'query' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate as 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: 'Search for poems by title' specifies the verb (search) and resource (poems), and 'Returns matching poems with their full text' adds output details. It distinguishes from 'poems_by_author' (search by author) and 'random_poems' (no search), but could be more explicit about sibling differentiation.

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

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

The description implies usage context: search by title rather than author or random selection, suggesting when to use this tool. However, it lacks explicit guidance on when to choose alternatives like 'poems_by_author' or 'random_poems', and no exclusions or prerequisites are mentioned.

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