Quickbooks

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

With no annotations, the description carries the full burden. It discloses that the tool routes to other data sources, which is a key behavioral trait. However, it doesn't mention any limitations or safety aspects.

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?

Extremely concise at 3 sentences, front-loaded with purpose, and includes actionable examples.

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

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

Given low complexity (1 param, no output schema), the description is nearly complete. It could mention the return type, but the examples implicitly show answers.

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 only one parameter, so baseline is 3. The description adds natural language context but no additional meaning beyond 'question'.

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 answers plain English questions by routing to the best data source, with examples that distinguish it from siblings like qb_query or discover_tools.

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

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

The description explicitly says to use plain English and provides examples, but does not mention when not to use it or compare to 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 the full burden. It discloses data sources (SEC EDGAR, FAERS, etc.) and return value (paired data + citation URIs), and notes efficiency gains. However, it does not mention any side effects, authorization needs, or error 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 moderately long but front-loads the core purpose and usage criteria. Every sentence adds value, though some redundancy (e.g., restating the number of entities) could be trimmed.

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 adequately covers inputs, outputs, data sources, and when to use. It lacks details on error handling or edge cases, but for the complexity of comparing two entity types, it 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 coverage is 100% with descriptions for both parameters. The description adds extra meaning by explaining the 'type' parameter's two use cases and detailing the 'values' parameter format with examples. This goes beyond the schema.

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

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

The description uses a specific verb ('compare') and resource ('entities' as companies or drugs) and clearly distinguishes from sibling tools like entity_profile (single entity) and ask_pipeworx (general query). It explicitly states the tool compares 2–5 entities side by side.

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 concrete use cases ('when a user says compare X and Y') and differentiates between company and drug types with examples. It does not mention when not to use or name alternative tools explicitly, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool searches a catalog and returns names and descriptions, but does not explain any side effects (e.g., no changes to data), performance characteristics, or limitations beyond the limit parameter. The description is adequate but not detailed; a 3 is appropriate.

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 key action and adding context about when to use it. Each sentence adds value: purpose, output, usage guidance. A score of 4 is appropriate as it is efficient but could potentially be even tighter.

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

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

Given the tool's simplicity (search tool, 2 params, no output schema), the description is complete: it explains purpose, output, and invocation order. It does not explain return format or pagination, but that is acceptable as the tool returns names and descriptions, and the limit parameter covers pagination. A 4 is appropriate.

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 description need not add much. It mentions the 'query' parameter by example ('analyze housing market trends'), which adds some semantic value beyond the schema's generic 'Natural language description'. However, it does not describe the 'limit' parameter, but the schema already provides its description and default. Baseline 3 is justified.

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 the Pipeworx tool catalog by describing what you need.' It specifies the verb 'search', the resource 'tool catalog', and the mechanism 'by describing what you need'. The added context 'Returns the most relevant tools with names and descriptions' further clarifies the output. This effectively distinguishes it from siblings, which are mostly QuickBooks operations or memory tools.

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

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

The description explicitly states when to use this tool: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This provides clear guidance on invocation order (FIRST) and the context (500+ tools). No alternatives are mentioned, but the exclusivity is implied by the 'FIRST' directive, which is sufficient.

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 must cover behavior. It lists the specific data returned (SEC filings, fundamentals, patents, news, LEI) and mentions pipeworx:// citation URIs. However, it does not disclose potential rate limits, cost, or whether the call is expensive. Still, the output details are fairly transparent for a read-only 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 appropriately sized (about 5 sentences) and front-loaded with purpose and examples. Every sentence adds crucial information without redundancy. The structure flows from purpose, to usage, to return details, to input format—clear 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 adequately explains the kinds of data returned (SEC, fundamentals, patents, news, LEI). However, it does not specify the exact fields or structure of each data type, which could be helpful for an agent to parse results. Still, for a multi-source aggregation tool, the description provides a complete enough overview.

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 descriptions for both parameters. The description adds value beyond the schema by clarifying that only 'company' type is supported, that value can be ticker or zero-padded CIK, and that names are not supported (redirecting to resolve_entity). This additional context makes parameter usage very clear.

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 starts with 'Get everything about a company in one call', using a specific verb and resource. It lists concrete use cases and distinguishes from sibling tools like resolve_entity by noting that names are not supported. The examples cover typical user intents, making the purpose immediately clear.

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 when-to-use scenarios ('when a user asks...') and when-not-to ('Names not supported — use resolve_entity first'). It also explains that this tool replaces calling 10+ other tools, offering clear guidance on when it is the preferred choice.

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 must disclose behavioral traits. It only states 'Delete' without indicating whether deletion is permanent, requires confirmation, or has side effects. No mention of authorization needs or data impact.

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

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

Single sentence, concise, front-loaded with verb and object. No 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?

Tool is simple with 1 param and no output schema. Description is minimal but misses behavioral context (e.g., idempotency, error handling) that would help an agent decide to use it.

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 'key' parameter. Description adds no further semantics beyond what the schema provides, 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 uses specific verb 'Delete' and resource 'stored memory by key'. Clearly states what the tool does. Distinguishes from sibling tools like 'recall' (read) and 'remember' (store).

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

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

No guidance on when to use this tool vs alternatives. Does not mention prerequisites or context, such as whether the key must exist beforehand.

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 that feedback affects roadmap, is rate-limited (5 per identifier per day), free, and doesn't count against tool-call quota. It does not mention what happens after submission, but for a feedback tool this is sufficient.

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 paragraph that front-loads the purpose. Every sentence is informative and necessary, with no fluff. Conciseness is ideal.

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

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

Given the tool's simplicity and lack of output schema, the description covers all essential aspects: purpose, usage scenarios, behavioral constraints, and parameter guidance. The nested 'context' object is briefly mentioned, but it's clear. A slight gap is the lack of mention of any response or acknowledgment.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema by explaining each enum value for 'type' with examples and guiding how to write the 'message' (specific, no end-user prompt). This enhances 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 explicitly states the tool's purpose: to tell the Pipeworx team about bugs, feature requests, data gaps, or praise. It clearly distinguishes from siblings like 'ask_pipeworx' by specifying the feedback channel.

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 concrete scenarios for use (bug, feature, data_gap, praise) and gives instructions on how to phrase feedback (in terms of tools/packs, not pasting prompts). It also mentions rate limits and that it's free, but does not explicitly state when not to use it.

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

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

No annotations provided, so description must carry full burden. It does not mention authorization requirements, rate limits, or any side effects. It only states it returns details, which is expected.

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, efficient and to the point. Front-loaded with the main action. Could be slightly improved by removing 'including name, email, phone, and balance' if schema details cover that, but still concise.

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 should clarify return format or fields. It lists some fields but not all. No guidance on error cases or what happens if ID not found. Tool is simple but description could be more complete.

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

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

Schema coverage is 100% for the single parameter 'id'. Description does not add extra meaning beyond the schema description 'QuickBooks Customer ID'. Baseline score of 3 applies.

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

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

Description clearly states the verb 'Get' and resource 'QuickBooks customer by ID'. It distinguishes from siblings like qb_list_invoices and qb_get_invoice. However, it does not explicitly differentiate from qb_query, which could also retrieve a customer.

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

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

No guidance on when to use this vs qb_query or other list tools. The description implies use when you have an ID, but does not state that qb_query might be alternative for custom filtering.

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

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

Annotations are empty, so the description must convey behavioral traits. It states 'Returns full invoice details including line items', which indicates the output is comprehensive. However, it does not mention any side effects, rate limits, or authentication requirements. For a read operation, this is acceptable but minimal.

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

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

The description is two short sentences with no filler words. It front-loads the key action and then adds the return value detail. Every sentence adds value.

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

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

Given the tool's low complexity (single required parameter, no nested objects, no output schema) and empty annotations, the description is nearly complete. It could mention that the ID is the QuickBooks internal ID, but the schema already covers that. No major 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 schema has 100% description coverage: the parameter 'id' is described as 'QuickBooks Invoice ID'. The description adds no further meaning beyond that. Baseline 3 is appropriate since schema already covers it 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 'Get a single QuickBooks invoice by ID', specifying the verb ('Get'), resource ('QuickBooks invoice'), and the method of identification ('by ID'). It also distinguishes itself from siblings like qb_list_invoices (which lists invoices) by focusing on a single invoice retrieval.

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

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

The description implies use when you need details of a specific invoice, but does not explicitly state when not to use it or mention alternatives like qb_list_invoices for multiple invoices. Context signals show a sibling tool qb_list_invoices, but no guidance is given on choosing between them.

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 burden. It describes a read operation ('list') with no mention of destructive side effects or auth needs. It doesn't disclose pagination behavior beyond max_results parameter, which is already in the schema. The description adds basic behavioral context but could be more thorough.

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

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

The description is two sentences, concise and front-loaded. It efficiently states purpose and return fields. Could be slightly more compact but is 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 is a simple list with one optional parameter and no output schema, the description is adequate but not complete. It doesn't mention the default max_results value (which is in the schema but not in the description) or note that results are paginated. No output schema means description could clarify return format further.

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% (max_results is fully described). The description adds no additional parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states it lists chart of accounts from QuickBooks and specifies the returned fields (name, type, balance, classification). However, it does not distinguish itself from sibling tools like qb_list_invoices or qb_get_customer, which are obviously different resources.

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

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

The description implies use when you need account listing data but provides no guidance on when not to use it or alternatives. Sibling tools like qb_query might be alternatives for custom queries, but this is not mentioned.

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 indicates a read operation (list) and mentions recency ('recent'), which adds some context. However, it does not disclose any pagination behavior beyond what the schema implies, nor potential performance impacts or authorization requirements.

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

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

The description is a single sentence that conveys the tool's purpose and return data without any filler. Every word adds value.

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

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

With no output schema, the description compensates by listing the fields returned. The tool has simple parameters fully described in the schema, and the description covers the core purpose and output. Some additional context about filtering or ordering could 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%, so the schema already documents both parameters. The description does not add parameter-specific meaning beyond the schema, but it does provide context for the return fields, which indirectly helps parameter interpretation. Given full schema coverage, a 4 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 lists recent invoices from QuickBooks and enumerates the specific fields returned (invoice number, customer, amount, due date, status), making it highly specific and distinguishable from siblings.

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 when to use (listing invoices) but does not explicitly differentiate from other list tools like qb_list_accounts or provide guidance on when not to use or 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, the description carries the full burden. It explains the tool executes queries against QBO data, which implies read behavior. However, it does not disclose potential side effects (is it read-only?), rate limits, or error handling. The examples suggest read-only, but not explicit.

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, front-loaded with purpose and immediately followed by concrete examples. No fluff, every sentence adds value.

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

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

Given a single required parameter, 100% schema coverage, and no output schema, the description adequately explains what the tool does and how to use it. The examples cover typical use cases. However, missing info on read-only nature and error behavior prevents a 5.

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 baseline is 3. The description adds meaning by providing example query strings and specifying the query language (SQL-like) and common entities (Customer, Invoice). This enriches understanding beyond the schema.

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

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

The description clearly states the tool runs SQL-like queries against QuickBooks Online data, and provides concrete examples. It distinguishes itself from sibling tools (like qb_get_customer, qb_get_invoice) by offering a generic querying interface.

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 when to use this tool (when needing custom queries) but does not explicitly mention when not to use it or alternatives like the specific getter tools. There is no guidance on query syntax limits or best practices.

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

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

No annotations provided, so the description carries the full burden. It states the tool retrieves a stored memory or lists all keys, which is transparent. However, it does not mention if the operation is read-only, whether it accesses persistent storage, or any side effects. With no annotations, more detail on behavioral traits would be beneficial.

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

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

The description is concise with two sentences. The first sentence states the core functionality, and the second provides usage context. No unnecessary words. Could be slightly more structured by front-loading the main action, but it's effective.

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

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

Given the simple tool with one optional parameter, no output schema, and no annotations, the description is fairly complete. It explains both modes of operation. However, it doesn't describe the return format (e.g., what the list of keys looks like or the structure of a retrieved memory). With no output schema, this gap could be filled.

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% (one parameter 'key' with description). The description adds the semantic that omitting the key lists all stored memories, which is not explicit in the schema. This adds value, but the schema already describes the parameter adequately, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves a memory by key or lists all memories when key is omitted. It specifies the resource (previously stored memory) and the action (retrieve/list). However, it does not differentiate from the 'forget' sibling tool, but the purpose is distinct enough.

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 says to use this tool to retrieve context saved earlier, implying when you need previous context. It doesn't explicitly say when not to use it or mention alternatives like 'ask_pipeworx' or 'discover_tools', but the context is clear for a memory retrieval tool.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool fans out to SEC EDGAR, GDELT, and USPTO in parallel, returns structured changes with count and citation URIs, and explains the 'since' parameter format. It does not mention potential rate limits or auth, but for a read-only tool this is 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 a single, well-structured paragraph. It front-loads the purpose with example queries, then details the data sources, parameter formats, and return structure. Every sentence adds value 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 complexity of combining three external sources, the description adequately covers the input and output. It mentions return fields (structured changes, count, citation URIs). However, it does not specify if results are limited or paginated, nor the order of results. An output schema would help, but the description is sufficient for initial selection.

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

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

Schema coverage is 100%, but the description adds significant value: it specifies that only 'company' type is supported, explains the 'since' parameter accepts ISO dates or relative shorthand with recommendations ('30d' for typical monitoring'), and clarifies that 'value' can be ticker or CIK. This far exceeds simple schema repetition.

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 finds 'what's new with a company in the last N days/months' and gives specific example queries. It distinguishes from sibling tools like entity_profile (which is for general profile) and compare_entities (which compares entities) by focusing on recent changes across multiple 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 example queries and contexts (e.g., 'what's happening with X?', 'news on Apple this month'), signaling when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools for other use cases, so a slight deduction.

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?

Without annotations, the description explicitly covers persistence behavior (authenticated vs. anonymous) and session lifetime, which are critical behavioral traits beyond 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 concise sentences, front-loaded with the core purpose, then usage guidance, then persistence details. No wasted words.

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

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

For a simple key-value store with no output schema, the description covers purpose, usage, and behavioral context adequately.

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

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

Schema coverage is 100% and includes examples for the key parameter; the description adds no further detail beyond what the schema provides.

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

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

The description uses specific verb-resource ('Store a key-value pair') and distinguishes from siblings like 'recall' and 'forget', clearly indicating memory management.

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?

It states when to use ('save intermediate findings, user preferences, or context across tool calls') and provides context on persistence differences between authenticated and anonymous sessions.

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

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

With no annotations, the description must convey behavioral traits. It explains the tool returns IDs (CIK, ticker, RxCUI, LEI) plus pipeworx:// citation URIs, and implies it is read-only (it 'looks up' identifiers). It does not detail error handling, rate limits, or what happens if the entity is not found, but for a lookup tool this is 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 a single, well-structured paragraph that front-loads the core purpose, then adds usage guidance, examples, and workflow context. Every sentence contributes meaningful information – no filler or repetition. It is concise yet comprehensive.

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

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

Given the absence of an output schema, the description adequately explains what the tool returns (IDs and citation URIs), the types of entities it handles, and the context of use. It covers the critical information needed for an agent to decide when and how to invoke this tool, making it complete for its purpose.

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 significant value by providing concrete examples for the 'value' parameter (e.g., 'Apple' → AAPL, 'Ozempic' → RxCUI 1991306) and clarifying the enum choices for 'type'. These examples help the agent understand expected input formats and output behavior beyond the schema.

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

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

The description clearly states the action ('look up canonical/official identifier') and the resources (company, drug). It lists specific ID systems (CIK, ticker, RxCUI, LEI) and gives concrete examples, making the purpose unmistakable. It effectively distinguishes from siblings by mentioning it replaces multiple lookup calls and should be used before other tools.

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

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

The description explicitly tells when to use the tool ('when a user mentions a name and you need the...') and provides a clear workflow instruction ('Use this BEFORE calling other tools that need official identifiers'). It also hints at efficiency gains ('Replaces 2–3 lookup calls'). While it doesn't explicitly state when not to use it, the guidance is strong and practical.

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; description carries full burden. It describes the return verdict, extracted form, actual value with citation, and that it replaces multiple calls. Lacks mention of external API dependency or latency but is otherwise transparent for a read-only query 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?

Description is about 5 sentences, front-loaded with purpose, includes examples, and no unnecessary words. Efficient and well-organized.

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 simplicity (1 param, no output schema, no annotations), the description is fairly complete: covers purpose, usage, scope, and output format. Could mention error handling or prerequisites but not essential.

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% for the single parameter 'claim', which already has a good description. The tool description adds extra context with examples and natural-language expectations, providing value beyond the schema.

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

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

Clearly states the tool fact-checks natural-language claims against authoritative sources, gives examples, and specifies scope (company-financial claims for US public companies). Distinguishes from siblings by noting it replaces multiple 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?

Explicitly says when to use: 'when an agent needs to check whether something a user said is true', provides query patterns, and notes limitations (v1 supports only company-financial claims).

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