httpcat

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 behaviors: it accepts natural language questions, automatically selects and invokes appropriate tools, and returns results. However, it doesn't mention limitations like rate limits, authentication needs, or potential errors. The description is helpful but could be more comprehensive about operational constraints.

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: the first sentence states the core functionality, the second explains the mechanism, the third provides usage guidance, and the fourth gives concrete examples. Every sentence adds value, with no redundancy or fluff. It's appropriately sized for a single-parameter tool with a straightforward purpose.

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 with automatic tool selection) and lack of annotations/output schema, the description does well to explain the core functionality and usage. However, it doesn't address potential limitations, error conditions, or result formats. For a tool that abstracts multiple operations, more detail about what happens behind the scenes 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 description coverage is 100%, with the single parameter 'question' well-documented in the schema as 'Your question or request in natural language'. The description adds minimal value beyond this, only reinforcing that questions should be 'in plain English'. It doesn't provide additional syntax, format, or constraint details, so the baseline score of 3 is appropriate.

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

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

The description clearly 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 suggesting other tools require browsing/learning schemas) and includes three concrete examples ('What is the US trade deficit with China?', 'Look up adverse events for ozempic', 'Get Apple's latest 10-K filing') that illustrate appropriate use cases.

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 data sources (SEC EDGAR, FDA), return format (paired data + URIs), and specific fields per type. It does not explicitly state read-only nature but implies it by describing a lookup/compare operation.

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

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

Two sentences efficiently cover purpose, constraints, return data, and efficiency. No redundant information. Front-loaded with primary action and entity count.

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

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

For a tool with 2 params and no output schema, the description fully explains input formats, expected outputs per type, and return elements (paired data, URIs). Complete and self-contained.

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 significant context: explains how type determines returned fields, gives examples for values parameter, and clarifies format per entity type. This enhances understanding beyond schema descriptions.

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

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

The description explicitly states the tool compares 2-5 entities side by side and lists specific return data for company and drug types. It distinguishes itself from sibling tools by noting it replaces sequential calls.

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

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

The description provides clear context for when to use (comparing multiple entities efficiently) but does not explicitly state when not to use or mention alternative tools. The efficiency claim implies use over sequential calls.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior well ('Returns the most relevant tools with names and descriptions'), indicating a read-only search operation. However, it lacks details on error handling, performance, or authentication needs, 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 front-loaded with the core purpose in the first sentence, followed by usage guidance, with zero wasted words. Both sentences earn their place by providing essential information efficiently, making it highly concise and well-structured.

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

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

Given the tool's moderate complexity (search operation with 2 parameters), no annotations, and no output schema, the description is largely complete for its purpose. It covers what the tool does and when to use it, but could improve by hinting at output format or limitations, though not strictly required without an 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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by implying the query parameter's purpose ('by describing what you need'), but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema handles most parameter semantics.

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

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

The description clearly states the specific action ('Search the Pipeworx tool catalog'), the resource ('tool catalog'), and the method ('by describing what you need'), with explicit differentiation from siblings by emphasizing its search functionality versus list_codes or get_status_cat. It uses precise verbs like 'search' and 'returns' to define 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?

The description provides explicit guidance on when to use this tool ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task'), including a clear condition (large catalog) and alternative context (finding tools for a task). It effectively distinguishes usage from potential siblings by positioning it as an initial discovery step.

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

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

With no annotations, the description carries full burden. It explains the tool returns pipeworx:// citation URIs and bundles multiple data sources. It mentions a limitation for federal contracts but does not discuss potential errors, rate limits, or data freshness. However, it provides adequate behavioral context 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?

The description is concise (one paragraph) and front-loaded with the purpose. It packs significant detail without excess verbiage. Slightly more structure (e.g., bullet points) could improve readability, but it is efficient.

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

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

Given the complexity of bundling multiple data sources, the description is fairly complete: it lists what data is returned, supported entity types, input formats, and alternatives. Output schema is missing, but the description mentions citation URIs. Minor gaps on pagination or result structure.

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 value beyond schema: it clarifies that type only supports 'company' and that value must be a ticker or CIK, with explicit 'use resolve_entity first' for names. This directly helps agents avoid errors.

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

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

The description clearly states it returns a 'full profile of an entity across every relevant Pipeworx pack in one call' and lists specific data sources (SEC filings, XBRL data, patents, news, LEI). It also distinguishes itself by noting it replaces 10-15 sequential calls.

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

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

The description explicitly tells when to use this tool (when needing a comprehensive profile) and when to use alternative: 'For federal contracts call usa_recipient_profile directly (too slow to bundle).' It also advises to use resolve_entity if only a name is available.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool deletes a stored memory, which implies a destructive mutation, but doesn't clarify if the deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., error handling for invalid keys). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence with zero wasted words. It is front-loaded with the core action ('Delete'), making it immediately understandable. Every part of the sentence earns its place by specifying the resource and method ('a stored memory by key').

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 tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., error handling, permanence), usage context (e.g., when to use vs. siblings), and output expectations. While the purpose is clear, the overall context for safe and effective use is insufficient given the tool's complexity as a mutation operation.

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 'key' fully documented as 'Memory key to delete'. The description adds minimal value beyond this, only reiterating 'by key' without providing additional context like key format, examples, or constraints. Given the high schema coverage, a 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 immediately understandable. It distinguishes from sibling tools like 'recall' (likely retrieves) and 'remember' (likely stores), though it doesn't explicitly mention these alternatives. The specificity of 'by key' adds clarity about how the deletion is targeted.

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

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

No guidance is provided on when to use this tool versus alternatives. While the description implies deletion of stored memories, it doesn't specify prerequisites (e.g., the memory must exist), exclusions (e.g., cannot delete non-existent keys), or direct comparisons to siblings like 'recall' or 'remember'. The agent must infer usage from the purpose alone.

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

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

With no annotations provided, the description carries the full burden. It discloses the output behavior ('Returns a direct URL to a cat photo'), which is helpful, but doesn't mention error handling (e.g., for invalid codes), rate limits, or authentication needs. It adds some value but lacks comprehensive behavioral context 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 two sentences with zero waste: the first states the purpose, and the second clarifies the return value. It's front-loaded and appropriately sized for a simple tool, making it easy to scan 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 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose and output, but lacks error handling details or explicit sibling differentiation. For a simple lookup tool, this is sufficient but could be slightly enhanced 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 the 'status_code' parameter with examples. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't specify valid code ranges or format details). Baseline 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 specific action ('Get the http.cat image URL'), identifies the resource ('for a given HTTP status code'), and distinguishes from the sibling tool 'list_codes' by focusing on retrieving a single image URL rather than listing codes. It provides a complete picture of what the tool does.

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 mentioning 'a given HTTP status code,' suggesting it's for when you have a specific code to look up. However, it doesn't explicitly state when to use this tool versus the sibling 'list_codes' (e.g., for browsing codes vs. getting an image for a known code) or provide any exclusions or prerequisites, leaving some guidance gaps.

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 lists codes with descriptions and image URLs, which is useful behavioral context. However, it does not mention potential limitations like rate limits, data freshness, or response format details, 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 a single, efficient sentence that front-loads the key information ('List common HTTP status codes') and adds necessary details ('with their descriptions and corresponding http.cat image URLs') without any wasted words. Every part of the 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 tool's low complexity (0 parameters, no annotations, no output schema), the description is complete enough for its purpose. It clearly states what the tool does and what information it provides. However, without an output schema, it could benefit from more detail on the return format, but this is a minor gap for such a simple tool.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description does not add parameter semantics, but this is acceptable as there are no parameters. A baseline of 4 is appropriate for tools with zero 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 ('List') and resources ('common HTTP status codes'), and distinguishes it from the sibling tool 'get_status_cat' by specifying it lists multiple codes with descriptions and image URLs, whereas the sibling likely retrieves a single code.

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

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

The description implies usage for retrieving a list of HTTP status codes with descriptions and image URLs, but does not explicitly state when to use this tool versus the sibling 'get_status_cat' or provide exclusions. The context is clear but lacks explicit alternatives or when-not 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. It discloses a rate limit ('5 messages per identifier per day') and states it's free. While it doesn't detail side effects or persistence, the feedback nature implies non-destructive behavior, and the rate limit is a key behavioral constraint.

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 at three sentences, front-loading the primary purpose. Each sentence adds value: purpose, use cases, content guidelines, and rate limit. It could be slightly more structured, but it avoids unnecessary words.

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

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

For a feedback tool with no output schema, the description covers purpose, usage, content guidance, and a behavioral constraint (rate limit). It lacks details on acknowledgment or what happens after submission, but the tool's simplicity means this is 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?

The schema covers 100% of parameters with detailed descriptions, including enum options for 'type' and a nested object for 'context'. The description adds modest value by advising not to include the end-user's prompt verbatim in 'message', but this is supplementary rather than essential.

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: 'Send feedback to the Pipeworx team'. It lists specific use cases (bug reports, feature requests, missing data, praise) and distinguishes itself from sibling tools like ask_pipeworx and discover_tools by focusing on feedback rather than general queries or tool discovery.

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 when-to-use scenarios ('Use for bug reports, feature requests, missing data, or praise') and includes content guidelines ('Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim'). It also mentions rate limits but does not explicitly compare to sibling tools for 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 the full burden of behavioral disclosure. It explains the tool's core behavior (retrieving or listing memories) and persistence across sessions, which is valuable. However, it lacks details on error handling (e.g., what happens if a key doesn't exist), performance characteristics, or data format of retrieved memories, leaving some behavioral aspects unclear.

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 and efficiently structured in two sentences: the first states the purpose and key usage, the second provides contextual guidance. Every sentence earns its place by adding critical information without redundancy, making it appropriately sized for the tool's complexity.

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

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

Given the tool's moderate complexity (one optional parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and parameter semantics effectively. However, without annotations or an output schema, it could benefit from more detail on return values (e.g., format of retrieved memories) to fully compensate for the lack of structured data.

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 documents the single parameter 'key' with its type and description. The description adds value by explaining the semantic effect of omitting the key ('omit to list all keys'), which clarifies the tool's dual functionality beyond what the schema alone provides, though it doesn't add syntax or format details.

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', 'all stored memories'), and distinguishes it from siblings like 'remember' (which presumably stores memories) and 'forget' (which presumably deletes them). It explicitly mentions retrieving context saved earlier in current or previous sessions.

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: 'Use this 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. This directly addresses when to use this tool versus alternatives like 'remember' for storage.

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 fully bears the burden. Reveals parallel fan-out to SEC, GDELT, USPTO, explains return format (structured changes, total_changes count, URIs), and describes the 'since' parameter format. Does not mention any destructive side effects, which is consistent with 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?

Description is a single compact paragraph of four sentences, front-loaded with purpose. No unnecessary words; every sentence adds substantive detail. Slightly dense but 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?

Without an output schema, the description compensates by detailing return fields (structured changes, total_changes, pipeworx URIs). Covers all parameters with usage examples. Provides sufficient context for an agent to invoke the tool correctly for typical monitoring or briefing tasks.

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%. Description adds valuable context beyond schema: clarifies that 'type' currently only supports 'company', provides examples for 'since' (ISO and relative), and explains 'value' as ticker or CIK. This enriches the agent's understanding.

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: reporting what's new about an entity since a given time, with a specific example type 'company'. It distinguishes from siblings by focusing on change detection and data source fan-out, though it doesn't explicitly name 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?

Provides explicit use cases: 'brief me on what happened with X' or change-monitoring workflows. Gives examples of acceptable relative time formats (7d, 30d, 3m, 1y) and suggests '30d' or '1m' for typical monitoring. Does not state when not to use or name alternative 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 key traits: it's a storage operation (implying mutation), specifies persistence differences ('authenticated users get persistent memory; anonymous sessions last 24 hours'), and hints at session scope. However, it doesn't cover potential errors, rate limits, or exact response behavior, leaving some 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: the first sentence states the core action, followed by usage context and behavioral details. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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 (2 required parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and key behavioral aspects like persistence. However, without annotations or an output schema, it doesn't detail return values or error handling, which could be beneficial for full transparency. It compensates well but has minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('key' and 'value') with examples. The description adds minimal value beyond the schema by implying the parameters are used for storage but doesn't provide additional syntax, constraints, or usage details. This meets the baseline of 3 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 with specific verbs ('store a key-value pair') and resource ('in your session memory'), distinguishing it from siblings like 'recall' (retrieval) and 'forget' (deletion). It explicitly mentions use cases ('save 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 provides clear context on when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but it does not explicitly state when not to use it or name alternatives. For example, it doesn't clarify if 'recall' should be used for retrieval instead, though this is implied. The guidance is helpful but lacks explicit exclusions or sibling comparisons.

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

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

With no annotations provided, the description carries the full burden. It discloses the output (ticker, CIK, company name, pipeworx:// URIs) and accepted input formats. It does not mention error handling, rate limits, or idempotency but adequately describes the core behavior for a read-only lookup.

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

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

Two sentences: first establishes purpose and scope, second details version, input formats, output, and benefit. 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?

Despite no output schema or annotations, the description fully explains input constraints, output fields, and the tool's value proposition. For a simple 2-parameter tool with clear behavior, no additional details are necessary.

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 parameters. The description adds value by providing concrete examples (AAPL, Apple), explaining the version constraint (v1 only supports 'company'), and clarifying the value parameter accepts multiple formats.

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 'entity', specifies it works across Pipeworx data sources, and provides concrete examples (AAPL, CIK, Apple). It distinguishes from sibling tools like ask_pipeworx or list_codes by its specific focus on entity resolution.

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 noting it replaces 2–3 lookup calls and giving input format examples. However, it does not explicitly state when not to use it or compare with alternatives. The context is clear but lacks exclusion 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, the description carries full transparency burden. It discloses the authoritative sources (SEC EDGAR + XBRL), possible verdicts, and output format (citation, delta). It does not mention side effects or destructive actions (none expected), but could explicitly state non-destructive nature or rate limits. 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?

The description is three sentences, front-loaded with purpose, scope, and outputs. Every sentence adds value without redundancy, making it highly concise and well-structured.

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

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

Given one simple parameter and no output schema, the description covers the tool's core functionality, supported domains, and output structure. It lacks details on error handling or edge cases, but is sufficient for most intents. Slight room for improvement.

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 'claim' parameter already described as a natural-language factual claim with examples. The main description does not add additional parameter semantics beyond what the schema provides, meeting the baseline expectation.

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 fact-checks natural-language claims against authoritative sources, details supported claim types (company-financial), and lists return values (verdict, structured form, value with citation, delta). It distinguishes itself from siblings by specifying its focused scope.

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 support to company-financial claims ('v1 supports company-financial claims'), implying when not to use. It also notes that it replaces 4–6 sequential agent calls, providing efficiency context. However, it does not explicitly mention alternatives or when to avoid this tool.

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