Coinmarketcap

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

Given no annotations, the description carries full burden. It explains the routing behavior, argument filling, and returns results, with examples. However, it does not discuss limitations, error handling, or potential latency, which would improve transparency.

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

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

The description is front-loaded with the primary purpose and usage, followed by a list of sources and examples. It is slightly lengthy but each sentence adds useful information; could be tightened without losing clarity.

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 tool functionality and examples well, but without an output schema, it omits details on the return format or structure of the result. For a complex tool, this leaves some ambiguity about what the agent can expect.

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 'question' is described as a natural language request. The description adds value by illustrating appropriate question formats via examples, but does not significantly expand beyond the schema's description, which already covers 100%.

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 is for answering natural-language questions by automatically selecting the right data source. It provides a comprehensive list of domains and concrete examples, making its purpose unmistakable and distinct 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 explicitly states when to use the tool: when a user asks open-ended questions like 'What is X?' or 'Find Y', and emphasizes that it routes across many sources, avoiding the need to pick a specific tool. However, it lacks explicit guidance on when not to use it.

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

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

With no annotations, the description must disclose behavioral traits. It only states 'List', implying a read operation, but does not mention pagination, rate limits, or side effects beyond what parameters imply. Minimal transparency.

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

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

The description is a single concise sentence with useful examples, no wasted words, and front-loaded with the core action.

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 minimal description, the tool lacks completeness. It does not describe return format, pagination behavior, or how categories are defined, leaving gaps for agent usage.

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 50% (only 'limit' has a description). The tool description does not explain the parameters or compensate for the missing schema details. 'start' remains undocumented.

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 'List' and the resource 'meta-categories' with concrete examples (DeFi, L1, NFTs, Memes), effectively distinguishing it from the sibling 'category' tool.

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 siblings like 'category' or 'discover_tools'. No exclusions or alternatives are 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?

Annotations are empty, so the description carries full burden for behavioral traits. It fails to disclose any behavior: no mention of whether results are paginated, what the output format is, or the effect of the 'convert' parameter. This is a significant gap.

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?

At only five words, the description is concise but lacks necessary details. It is not overly verbose, but the brevity comes at the cost of completeness.

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 has 2 parameters, no output schema, and empty annotations, the description is grossly incomplete. It does not explain the return format, the 'convert' parameter, or how to use the tool effectively.

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

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

Schema coverage is 50% (only 'id' has a description). The description adds no meaning beyond the schema; it does not explain the 'convert' parameter or clarify usage of 'id'. With low coverage, the description should compensate, but it does not.

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 states 'Coins belonging to a specific category,' implying the tool retrieves coins filtered by category. However, it lacks an explicit verb like 'list' or 'get,' making the purpose somewhat vague. It does distinguish from the sibling 'categories' tool, which likely lists categories themselves.

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

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

No guidance is provided on when to use this tool versus alternatives. The sibling 'categories' is not mentioned, and there is no indication of when not to use 'category' (e.g., if a different filtering method is preferred).

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 fully disclose behavior. It does so by explaining the data sources (SEC EDGAR/XBRL for companies, FAERS for drugs) and the types of data pulled (revenue, net income, cash, debt, adverse events, approvals, trials). However, it does not mention potential limitations (e.g., errors for invalid tickers), rate limits, or authentication needs, which would improve transparency.

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

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

The description is well-structured with the main purpose first, followed by details and examples. It is slightly verbose but every sentence adds value. For example, the list of user queries and the explanation of data sources are necessary. It could be tightened slightly, but overall 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 tool's complexity and lack of output schema, the description adequately covers return values (paired data + citation URIs). However, it omits details on error handling, pagination, or performance implications. For a comparison tool that replaces multiple calls, these aspects could be important for an agent to use effectively.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by explaining the enum values ('company' and 'drug') and providing concrete examples for the 'values' parameter (e.g., tickers for companies, drug names). This helps an agent construct correct inputs beyond what the schema alone 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 clearly states the tool compares 2-5 companies or drugs side by side, with specific use cases ('compare X and Y', 'X vs Y', 'how do X, Y, Z stack up', 'which is bigger'). It distinguishes from sibling tools by noting it replaces 8-15 sequential agent calls, making its purpose unique and identifiable.

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 provides when to use the tool, including example user queries for comparisons and rankings. It also implies when not to use sequential calls by stating it replaces them. While it doesn't name alternatives, the context signals indicate siblings like entity_profile could be alternatives for individual lookups.

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 states it returns top-N most relevant tools with names and descriptions. It lacks details on relevance ranking or error handling, but is adequate for a simple search tool.

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

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

Front-loaded with purpose, includes helpful examples. Slightly verbose due to list of domains, but well-structured and each 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 no output schema, the description explains the return value (top-N tools with names+descriptions). Sufficient for a discovery tool, though could mention if results are sorted by relevance.

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%; both query (natural language) and limit (max 50) are documented. The description adds context for query but does not significantly extend 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 it finds tools by describing data or task, provides a wide range of example domains, and distinguishes itself from siblings by being a discovery tool rather than a specific operation tool.

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 'Use when you need to browse, search, look up, or discover what tools exist for...' and advises to call it FIRST for exploring options, giving clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description fully discloses the tool's output: SEC filings, fundamentals, patents, news, and LEI with citation URIs. It implies a read-only operation, and no contradictory or missing behavioral information is present.

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 and front-loaded with the main purpose. It efficiently conveys usage examples, return data, and parameter hints in a few sentences without unnecessary detail. Every sentence earns its place.

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

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

Given the absence of an output schema, the description thoroughly explains the return values (filings, fundamentals, patents, news, LEI) and cites the citation mechanism. It covers all necessary aspects for an agent to understand and invoke the tool correctly.

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

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

The description adds value beyond the input schema by clarifying that 'type' is currently limited to 'company' and explaining that 'value' can be a ticker or CIK. It also notes that names are unsupported and suggests using resolve_entity, which enriches parameter 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 fetches all available information about a company in a single call, distinguishing it from sibling tools like resolve_entity and compare_entities. It specifies the verb 'Get everything' and the resource 'a company', making the purpose unambiguous.

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

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

The description provides explicit usage examples ('tell me about X', 'research Microsoft') and explains when to use this tool instead of calling multiple individual tools. It also advises against using names directly, directing users to resolve_entity first, which is helpful 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?

Despite no annotations, the description clearly indicates destructive behavior ('Delete'). It could mention irreversibility, but overall it transparently communicates the core action.

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, no fluff. First sentence states purpose, second adds usage context. Efficiently conveys all necessary information.

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

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

For a simple tool with one parameter and no output schema, the description is complete. It covers purpose, usage, and context. Minor omission: no mention of error cases or confirmation.

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 parameter description is clear. The description doesn't add significant meaning beyond the schema, though it implies the key must exist from prior storage.

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 a previously stored memory by key'), specifying the verb and resource. It distinguishes itself from siblings like 'remember' and 'recall' by focusing on deletion.

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 scenarios for use: stale context, task completion, clearing sensitive data. Also recommends pairing with 'remember' and 'recall', giving clear guidance on when to use this 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?

No annotations exist, and the description lacks behavioral context such as whether data is live or cached, idempotency, or any side effects. For a read-only data tool, this is a minimal disclosure.

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 short but reads as a list rather than a complete sentence. It is efficient but could benefit from a clearer structure or introductory verb.

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 tool has no output schema or annotations, so the description bears full responsibility. It omits details like data freshness, source, or whether it returns a single object or multiple entries, leaving gaps for an agent.

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

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

Schema description coverage is 100% for the single 'convert' parameter. The description adds no additional meaning beyond what the schema provides, hence baseline score.

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 lists the specific metrics provided (market cap, volume, dominance, active cryptos) and distinguishes from sibling tools like quotes or listings_latest.

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 a data retrieval tool but does not explicitly state when to use it or provide alternatives. However, the name and context make the purpose reasonably 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 must disclose behavior. It only states the output scope (top-ranked coins by market cap) but does not mention sorting, pagination, error handling, or any side effects. Schema parameters imply sorting and filtering, but description adds no context.

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 single sentence. Front-loaded with key information. However, it could be slightly more informative without losing conciseness, e.g., 'List top-ranked coins by market cap with optional sorting and pagination.'

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, so description should compensate by describing return format. It does not mention what fields each coin includes (e.g., name, symbol, price, market cap). Also lacks details on pagination behavior (e.g., total count).

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% description coverage, so baseline is 3. The description adds no additional meaning beyond what each parameter already describes. It does not explain how parameters interact or affect results.

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

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

Description clearly states it returns top-ranked coins by market cap. Verb is implied (list/get), resource is coins, and it distinguishes from sibling tools that focus on categories, quotes, or changes. However, it lacks an explicit verb like 'list' or 'get'.

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 'quotes' or 'categories'. There is no mention of prerequisites, typical use cases, or when not to use it. The description is purely declarative.

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 description must disclose behavior. 'Static' implies read-only and no side effects, but there is no mention of response format, pagination, rate limits, or error handling. The description adds minimal behavioral context.

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?

One efficient sentence that immediately conveys purpose. No wasted words, though a bit more context could be added without harming conciseness.

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 output schema and annotations, the description fails to explain response structure, parameter interaction, or constraints. For a simple static data tool, it is minimal but missing details on parameter precedence and output format.

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 clear parameter descriptions. The description adds no extra meaning beyond what the schema provides for 'id' and 'symbol', 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 provides static coin metadata including logo, description, website, social links. This verb+resource is specific and easily distinguishes from dynamic data tools like quotes or global_metrics.

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 explicit guidance on when to use this tool versus alternatives. While the description implies it is for static data, it does not compare to siblings like entity_profile or resolve_entity, leaving the agent uncertain about selection criteria.

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 fully discloses behavioral traits: rate-limited to 5 per identifier per day, free, doesn't count against quota, and expects tool-specific feedback not end-user prompts.

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 succinct and front-loaded with purpose, then usage, then constraints. 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?

Despite no output schema, the description fully covers what the agent needs to know: purpose, when to use, behavioral constraints, and how to structure feedback. It is complete for a simple feedback submission 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?

Schema description coverage is 100% with clear parameter descriptions. The description adds context about usage but does not significantly enhance what the schema already provides for 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: reporting bugs, missing features, data gaps, or praise to the Pipeworx team. It distinguishes from sibling tools (which are data query tools) by its unique feedback function.

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

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

The description explicitly specifies when to use the tool for each feedback type (bug, feature/data_gap, praise) and includes important constraints like rate limits and that it's free.

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 present, so the description carries the full burden. It only states it provides 'latest' quotes, but does not disclose behavior for invalid inputs, simultaneous id/symbol usage, rate limits, or authentication. This is insufficient 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?

Two sentences with no redundancy. The essential information is front-loaded, covering purpose and identification methods efficiently.

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 should ideally hint at the response structure or error handling. It mentions 'latest market quotes' but gives no details on the return format. For a simple tool, this is minimally adequate.

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

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

The schema already covers parameters 100%, but the description adds value by clarifying the OR relationship between 'id' and 'symbol', providing examples (e.g., 'BTC,ETH'), and noting the default for 'convert' (USD). This goes beyond baseline 3.

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 'Latest market quotes for one or more cryptocurrencies' with specific verb 'get quotes.' However, it does not explicitly differentiate from sibling tools like 'listings_latest' or 'categories,' so it misses the opportunity to clarify its unique role.

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 how to identify cryptocurrencies (by symbol or ID) but provides no guidance on when to use this tool versus alternatives like 'listings_latest' or 'categories.' Usage context is implied but not explicit.

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 disclose behavior. It reveals that the tool is read-only, scoped to an identifier, and can list all keys when 'key' is omitted. It does not mention any destructive aspects (correctly, as it is read-only). The description is transparent about its retrieval nature.

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: three sentences that are front-loaded with the core purpose. Every sentence contributes unique 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?

Given the simple input schema (one optional parameter) and no output schema, the description adequately explains what the tool returns (a value or list of keys). It covers scoping, usage context, and pairing with sibling tools, making it complete for an agent.

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

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

Schema coverage is 100%, and the description adds value by explaining the parameter's role ('omit to list all keys') and overall usage context (pairing with remember/forget). This goes beyond the schema's basic description.

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

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

The description clearly states the tool's function: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It uses specific verbs and resources, and distinguishes from sibling tools by mentioning 'remember' and '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 clear guidance on when to use the tool: 'Use to look up context the agent stored earlier... without re-deriving it from scratch.' It also notes scoping and pairing with remember/forget. However, it doesn't explicitly mention when not to use or list 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?

Without annotations, the description carries full burden. It discloses the parallel fan-out to three external sources (SEC EDGAR, GDELT, USPTO) and the return format (structured changes + count + URIs). It does not mention rate limits, cost, or potential delays, but the behavior is sufficiently transparent for a read-only aggregation 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 two sentences, front-loaded with the core purpose. Every sentence adds unique value: purpose, usage triggers, data sources, parameter format, and return structure. No redundant or filler content.

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 (three parameters, no output schema), the description adequately covers purpose, parameters, and return value. It does not explain pagination or result limits, but for a real-time aggregation tool this is acceptable.

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 clarification for the 'since' parameter (ISO date or relative shorthand like '7d', '30d') and notes 'type' only supports 'company'. This is helpful but does not significantly exceed 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?

The description clearly states the tool's purpose: answering 'What's new with a company in the last N days/months?' and provides specific verb 'fan out' to multiple data sources. It explicitly lists example user queries and distinguishes the tool as a focused change-monitoring function among many 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 gives concrete example queries that trigger use ('what's happening with X?', 'any updates on Y?') and mentions monitoring use cases. However, it does not specify when NOT to use this tool or mention alternative tools for similar tasks.

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, description carries full burden. It discloses persistence behavior: authenticated users get persistent memory, anonymous sessions retain for 24 hours. Implies write operation without stating it explicitly, which 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?

Five short sentences, no fluff. Purpose is front-loaded. Every sentence adds value: purpose, when to use, storage mechanism, persistence, and pairing with siblings.

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 purpose, usage, behavioral details, and pairing. Minor gap: no mention of return value, but for a save operation the agent can infer success from typical behavior. Otherwise complete.

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

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

Schema description coverage is 100%, baseline 3. Description adds extra meaning: mentions key-value pair scoping by identifier and gives example key patterns, which helps the agent understand usage 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?

The description clearly states the action: 'Save data the agent will need to reuse later.' It specifies the resource (data as key-value pairs) and scope (scoped by identifier). It also distinguishes from sibling tools recall and forget by naming them.

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

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

Explicitly states when to use: when discovering something worth carrying forward. Provides alternatives: 'Pair with recall to retrieve later, forget to delete.' Gives examples of good keys.

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 of IDs plus citation URIs, and hints at multiple ID types per entity. However, with no annotations, it lacks details on error handling, authentication requirements, or rate limits—leaving some behavioral gaps for a production 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?

Four dense sentences with no fluff. Purpose is front-loaded, examples are immediate, and usage guidance is the final sentence. Every sentence earns its place.

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

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

Despite no output schema, the description fully explains what is returned (IDs + citation URIs) and the ID systems involved. It covers the main use case and efficiency gain, leaving no critical gaps for a lookup 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?

Schema covers both parameters with 100% description. Description adds value by illustrating valid inputs (e.g., 'AAPL', '0000320193', 'ozempic') and explaining that output includes multiple IDs, surpassing baseline schema info.

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 'looks up the canonical/official identifier' for companies and drugs, specifying exact ID systems (CIK, ticker, RxCUI, LEI). Distinguishes itself from sibling tools like 'entity_profile' and 'categories' by focusing on ID resolution needed for 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?

Explicitly advises to use 'BEFORE calling other tools that need official identifiers'. Provides concrete examples (Apple→AAPL/CIK, Ozempic→RxCUI) and states it replaces 2-3 lookup calls, giving clear context for when to invoke.

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 discloses the return verdict types, output structure (actual value with citation, percent delta), and scope (v1 supports company-financial claims via SEC EDGAR). It does not mention rate limits or authentication but is otherwise 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 concise (no wasted words), front-loaded with the action, followed by usage guidance, scope limitations, and output details. 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 simple input schema (1 required param, no output schema, no annotations), the description is fairly complete: it explains purpose, usage, domain scope, output structure, and efficiency. It could mention prerequisites or error handling, but current info 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the type of natural-language claims accepted and providing examples, which helps the agent understand the parameter's expected input.

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 action (fact-check, verify, validate) and resource (natural-language factual claims). It distinguishes itself from sibling tools by noting it replaces 4-6 sequential calls and specifies the domain (company-financial claims).

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

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

The description explicitly states when to use the tool (e.g., 'check whether something a user said is true') with example queries. However, it does not explicitly state when not to use it or list alternative tools.

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