Always Seven

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

Annotations are absent; description carries full burden. Claims randomness but name suggests deterministic behavior. No disclosure that parameters are ignored. Contradicts implied 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?

Very short (two sentences) but omits essential behavioral details. Not overly verbose, but incomplete.

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 deceptive simplicity (always returns seven despite name and description suggesting randomness), the description should clarify this. Without output schema details, it is insufficient.

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 parameter descriptions. But description adds no value; does not mention that parameters do not affect output, which is crucial for correct usage.

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

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

Description states 'generate a random number between 1 and 10', but the tool name 'always_seven_generate' implies the result is always seven, creating confusion. No differentiation from sibling 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?

No guidance on when to use this tool versus alternatives like other generation tools. No when-to-use or when-not-to-use information.

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 disclose behavioral traits. It explains the tool internally selects and invokes other tools, which is helpful transparency. However, it does not mention any side effects, authorization needs, or limits (e.g., latency, rate limits).

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

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

The description is concise (3 sentences) and front-loaded with the core purpose. Examples add value without verbosity. Slightly verbose with 'No need to browse tools...' but overall 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 simplicity (1 param, no output schema), the description is mostly complete. It explains the tool's unique behavior of selecting sub-tools. However, it lacks information about response format or what happens if the tool cannot answer, which would be helpful.

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

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

Schema coverage is 100% with a single 'question' parameter. The description adds value by explaining the parameter as a natural language request and providing example queries, going beyond the schema's generic 'Your question or request in natural language'.

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 takes a plain English question and returns an answer from the best data source. It distinguishes from sibling tools like 'always_seven_generate' by emphasizing natural language querying and automated 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 provides usage examples ('What is the US trade deficit...') but lacks explicit when-to-use or when-not-to-use guidance. It implies the tool is for queries where the agent should figure out the approach, but does not exclude cases where direct tool calls might be better.

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 already declare readOnlyHint=true and openWorldHint=true. The description adds significant context: it resolves the market, classifies bet types, fans out to relevant data packs, and returns an evidence packet with comparison. No contradictions with 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 informative and front-loaded with purpose. It is moderately concise, though some sentences could be tightened. Overall, it earns its length without being overly verbose.

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

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

The description covers the tool's core functionality, inputs, output (evidence packet + comparison), and use cases. Without an output schema, it adequately describes return values. Slight gap: no details on the comparison format or evidence 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% and includes clear explanations for both parameters. The tool description repeats this information but adds no new details beyond what the schema provides. Thus, 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 researches a Polymarket bet by pulling relevant Pipeworx data. It specifies the resource ('Polymarket bet') and verb ('Research'), and differentiates from siblings by focusing on bet research and market edge analysis, which is distinct from general Q&A or entity comparison 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 provides explicit use cases: 'should I bet on X?', 'what does the data say about this Polymarket market?', or 'is there edge in this bet?'. It implicitly excludes other types of queries handled by siblings like ask_pipeworx, though it 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 are provided, so the description must carry the full burden. It discloses the data returned per type and mentions output includes paired data and URIs, but does not state that the tool is read-only or any potential side effects, leaving some ambiguity.

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, front-loaded with the core functionality, every sentence adds necessary information, and no redundant text exists.

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, the description provides a good overview of returned data per type. However, it lacks specifics on the exact structure of 'paired data' and resource URIs, which could help an agent use the results 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 coverage is 100%, so baseline is 3. The description adds value by explaining parameter usage in context (e.g., tickers/CIKs for company, names for drug) and the allowed count range, which goes beyond the schema's basic requirements.

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 compares 2-5 entities side by side in one call, distinguishes between company and drug types, and explicitly mentions it replaces 8-15 sequential calls, setting it apart 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 indicates when to use the tool (for side-by-side comparison of multiple entities) and specifies type-dependent behavior, but does not explicitly state when not to use it or mention alternatives beyond the replacement claim.

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 behavioral traits. It states the tool returns the most relevant tools with names and descriptions, but does not disclose performance characteristics, auth needs, or any side effects. With zero annotation coverage, more detail would be beneficial, but the core behavior is clear.

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 long, front-loaded with the core purpose, and each sentence adds value. No wasted words.

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

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

Given the low complexity (2 params, no output schema), the description is largely complete. It covers purpose, when to use, and return type. A slight deduction for not mentioning that the tool is read-only or any rate limits, but overall sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not elaborate on the 'query' or 'limit' parameters. However, since the schema already describes them well, the description is not required to repeat.

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 ('search') and resource ('Pipeworx tool catalog'), and specifies its purpose: finding relevant tools among 500+ options. It distinguishes itself from sibling tools, which are unrelated (e.g., 'ask_pipeworx', 'remember').

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

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

Explicitly instructs to call this tool first when many tools are available, providing a clear usage scenario. No sibling tool serves the same discovery function, so no alternative is needed, but the guidance is strong.

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 return format (pipeworx:// citation URIs) and notes it replaces many calls (implying it's a single heavy call). Lacks explicit idempotency or side-effect info, but sufficient for a read 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 dense but well-structured: purpose first, then details, then a clear usage note. 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 no output schema and no annotations, the description covers return format, parameter constraints, and alternatives. Could mention any rate limits or pagination, but it's sufficient for typical use.

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

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

Schema coverage is 100%, but the description adds value beyond schema: specifies that only 'company' is supported, and clarifies that 'value' must be a ticker or CIK, not a name, with a directive to use 'resolve_entity' first.

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

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

The description clearly states it provides a 'full profile of an entity across every relevant Pipeworx pack in one call' with detailed data sources. It distinguishes from the sibling tool 'usa_recipient_profile' and implies differentiation from '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?

Explicitly tells when to use this tool (for broad company profiles) and when to use an alternative ('For federal contracts call usa_recipient_profile directly'). Also advises using 'resolve_entity' first 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 provided, so the description must carry full behavioral weight. It states the core action (delete) but does not disclose side effects (e.g., cascading deletions, permission requirements, or whether deletion is permanent). Since the description is minimal but accurate, a middle score 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 a single sentence that fully captures the tool's purpose. Every word is necessary; there is no redundancy or filler.

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 (single parameter, no output schema, no annotations), the description adequately covers the essential information. It could mention that the deletion is irreversible or confirm success, but for a straightforward delete operation, it is sufficiently complete.

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

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

The description adds minimal value over the schema: the schema already describes 'key' as 'Memory key to delete'. The description reinforces the purpose but does not elaborate on format constraints or examples. However, with 100% schema coverage, baseline is 3; the extra clarity on the action raises it to 4.

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

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

The description clearly states the action ('Delete'), the resource ('stored memory'), and the means ('by key'). It directly distinguishes from sibling tools like 'remember' (create) and 'recall' (retrieve), 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 implies usage when you know the memory key and want to delete it, but does not explicitly state when not to use it or mention alternatives. No comparison to other deletion mechanisms (if any) or context on irreversible effects.

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 carries the full burden. It discloses rate limiting ('Rate-limited to 5 messages per identifier per day') and that it is 'Free.' It also provides behavioral guidance on feedback content. This is sufficient for a simple feedback tool.

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

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

The description is very concise: three sentences that front-load the purpose, then provide usage guidelines and rate limit info. 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 feedback tool with no output schema, the description covers all essential aspects: purpose, usage, parameter types (with schema providing details), and rate limiting. The nested context object is mentioned as optional, which 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 input schema has 100% description coverage for all parameters. The description adds value by reinforcing the enum meanings and providing context on message content, but it does not significantly extend 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's purpose: 'Send feedback to the Pipeworx team.' It enumerates specific use cases (bug reports, feature requests, missing data, praise) and distinguishes itself from sibling tools, none of which handle feedback.

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 ('Use for bug reports, feature requests, missing data, or praise') and provides concrete guidance on what to include ('Describe what you tried in terms of Pipeworx tools/data') and what to exclude ('do not include the end-user's prompt verbatim'). It also mentions rate limiting. However, it 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?

Annotations set readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description aligns with these. It adds behavioral context beyond annotations by explaining the two modes and how cross-event mode works. No contradictions. It could disclose more about potential side effects (e.g., network calls), but overall 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 well-structured, front-loaded with the purpose, and each sentence adds value. It explains two modes concisely without extraneous information. It is appropriately sized for the 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 no output schema, the description still mentions that returns are 'ranked opportunities with suggested trade direction + reasoning', which is helpful. It covers the tool's behavior and modes sufficiently. Could be more specific about the output format, but it is complete enough for an agent to understand the 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?

Both parameters ('event' and 'topic') are described in the schema with 100% coverage. The description adds meaning beyond the schema by explaining the modes corresponding to each parameter and giving concrete examples. This meets the criteria for a 4.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities by checking monotonicity violations on Polymarket. It specifies two modes (event and topic) and provides examples. However, it does not explicitly distinguish this tool from sibling tools like 'polymarket_edges' or 'validate_claim', which would justify a 5.

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

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

The description explains when to use each mode, with examples for both event and topic modes. It highlights that cross-event mode is needed for cases where single-event mode misses opportunities. However, it does not explicitly state when not to use the tool or compare it to alternatives, which would make it a 5.

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 already indicate read-only, open-world, non-destructive. Description adds valuable context: groups by asset, fetches price history once, computes model probability, ranks by |edge|, returns suggested trade direction. No contradiction.

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. Second sentence is dense but clear. Every part adds value; could be slightly more concise but 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?

No output schema, but description explains output format. Algorithm and scope (V1 crypto-only) are described. Parameters fully covered. Sufficient 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 covers all 3 parameters with descriptions; description reinforces limit and min_edge_pp but adds no new meaning beyond schema. 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?

Clearly states it scans high-volume Polymarket markets and returns those with largest disagreement between Pipeworx data and market price. Specifies it covers crypto-price bets using a lognormal model. Distinct from sibling polymarket_arbitrage.

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 built for 'what should I bet on today' and notes it saves paging through hundreds of markets. Lacks explicit when-not-to-use or comparison to alternative tools, but 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 description carries full burden. It states the tool retrieves or lists, but doesn't disclose behavioral traits like persistence across sessions, potential data loss, or idempotency. The description adds some context (sessions) but not deep behavioral detail.

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 action and use case. No wasted words.

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

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

Given single optional parameter, no output schema, and no annotations, the description adequately covers what the tool does and how to use it. Could mention that listing all keys returns key names but not values, but not necessary for completeness.

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

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

Schema coverage is 100% with one parameter described in schema. Description adds context about omitting key to list all, which is already implied by schema (key not required). Minimal added value beyond schema.

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

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

Description clearly states the tool retrieves a memory by key or lists all memories, which is a specific verb+resource. However, it doesn't differentiate from sibling tools like 'forget' or 'remember', though 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?

Description provides clear guidance: use key to retrieve specific memory, omit key to list all. It also mentions retrieving context saved earlier, which implies when to use. However, it doesn't explicitly state when not to use or compare to alternatives.

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

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

No annotations provided, but the description discloses key behaviors: parallel fan-out to SEC EDGAR, GDELT, USPTO; accepted since formats; output structure includes changes, count, and URIs. Could add latency or read-only hint.

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 with no redundancy. First sentence defines core function and data sources; second sentence details parameters and output. Every phrase is informative.

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 tool behavior, parameters, and output. Could mention if it's read-only, but overall 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?

Input schema has 100% coverage, baseline 3. The description adds value by explaining the 'type' enum (only company), 'since' formats with examples, and 'value' as ticker or CIK. Exceeds baseline.

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 recent changes for an entity since a given time. It specifies the verb 'fans out' and the resource (entity changes), and contrasts with sibling tools by focusing on temporal deltas.

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 like 'brief me on what happened with X' and change monitoring. It does not mention when not to use or name alternatives, 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 provided, so description carries full burden. It discloses persistence differences: 'Authenticated users get persistent memory; anonymous sessions last 24 hours.' This is crucial behavioral context beyond basic 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?

Three sentences, each adding unique value: function, use cases, and behavioral nuance. No fluff.

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 2 simple parameters and no output schema, the description is nearly complete. Could mention that values overwrite on duplicate key, 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 already has 100% coverage with descriptive parameter names and descriptions. The description does not add further parameter details, 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?

Description clearly states the tool stores key-value pairs in session memory. It uses specific verbs ('store', 'save') and identifies the resource ('session memory'). This effectively differentiates from siblings like 'recall' (retrieve) and 'forget' (delete).

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

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

Description explains when to use: 'save intermediate findings, user preferences, or context across tool calls.' It does not explicitly state when not to use or mention alternatives, but context from sibling names suggests it complements recall and 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?

With no annotations, the description must convey behavioral traits. It mentions accepted input forms (ticker, CIK, name) and returned fields (ticker, CIK, name, URIs), but lacks details on authorization, rate limits, or error handling. This is adequate for a simple lookup but not comprehensive.

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 no redundant words. The first sentence states the core purpose, and the second provides key details and benefits. 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?

For a simple two-parameter tool with no output schema, the description covers the inputs, outputs, and efficiency benefit. It lacks example usage or error scenarios, but for a straightforward resolver, it is reasonably complete.

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

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

The input schema already provides descriptions for both parameters (type and value) with 100% coverage and an enum for type. The description adds examples and context (v1 supports company) but does not substantially enhance the semantic 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's purpose: 'Resolve an entity to canonical IDs across Pipeworx data sources in a single call.' It specifies the action, resource, and scope, and its focus on canonical IDs distinguishes it from sibling tools like ask_pipeworx or forget.

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 context for when to use this tool (instead of 2–3 lookup calls) and notes that v1 supports only 'company', implying limitations. However, it does not explicitly state when not to use it or suggest 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?

Discloses return values and that it replaces multiple agent calls, but does not mention any limitations, edge cases, or whether the operation is read-only (no annotation provided). Lacks clarity on potential errors or source quality.

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, no redundant words, front-loaded with main purpose, efficient structure.

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 tool with one parameter and no output schema, the description explains functionality, return values, and scope adequately. Could mention authentication or error handling but not critical.

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 only parameter 'claim' is fully described in the input schema (100% coverage) with examples. The description adds no new information beyond what the schema already 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?

Clearly states it fact-checks natural-language claims against authoritative sources, specifically company-financial claims via SEC EDGAR+XBRL. Lists specific return values (verdict, structured form, actual value with citation, percent delta) and distinguishes from siblings by noting it replaces 4-6 sequential agent calls.

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

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

Indicates scope (v1 supports company-financial claims for public US companies), implying it's not for other claim types. Does not explicitly state when not to use or name alternatives, but the sibling list provides context.

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