Alchemy Eth

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds critical behavioral details: default model, optional Anthropic with cost implications, and return format ({score, confidence, signals, raw_response} + combined view). No contradictions.

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: first sentence states core purpose and scoring, second explains model options and API key, third lists return format and use cases. Front-loaded with essential info, no redundant words.

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

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

Despite no output schema, the description explicitly details the return structure. Covers all parameters and use cases. Could include more on how 'signals' or 'confidence' are derived, but adequate for an agent to understand what the tool does and returns.

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 the relationship between 'models' and '_apiKey' (Anthropic requires key), providing concrete examples for 'entity' (e.g., 'Pipeworx'), and clarifying that 'context' disambiguates common names.

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 ('Probe'), resource ('LLMs'), and output ('score visibility (0-100) per model'). It clearly distinguishes this tool from siblings like 'entity_profile' or 'scan_competitor_ai_presence' by focusing on AI visibility scoring across multiple models.

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 use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and notes that Anthropic probing requires a BYO API key. Does not explicitly exclude other tools but provides enough context for an agent to decide when to invoke 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about routing, argument filling, citation URIs, and the scale of sources (2,789 tools, 604 sources), which goes beyond annotations. No contradictions.

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 key preference directive and remains informative. It could be slightly more concise but every sentence adds value, covering purpose, examples, and outcomes.

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 single-parameter tool without output schema, the description explains query scope and result type (structured answer with citations) but lacks detail on response format, error handling, or limitations. Partial 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% for the single parameter 'question'. The description adds example queries but does not add new semantic constraints or formats beyond the schema. Baseline 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?

The description clearly states that the tool answers factual questions about real-world entities using authoritative structured data from many sources, and explicitly distinguishes itself from web search with a preference directive. Examples cover diverse domains, making 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 gives explicit guidance to prefer this tool over web search for specific data types, lists example queries, and implies when to use it. It contrasts with alternatives (web search) and provides concrete use cases.

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

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

Annotations (readOnlyHint, idempotentHint, etc.) already cover the safety profile, but the description adds no behavioral context beyond 'feed', which is ambiguous. It does not disclose what the feed contains, whether it supports filtering, or how results are paginated.

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 extremely concise (one phrase), but it sacrifices informativeness for brevity. It is not front-loaded with key action and resource, and the word 'enhanced' adds confusion without explanation.

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 presence of an output schema and no input parameters, the description is still too vague. It does not explain what 'transfer feed' means, what entities are included (ERC20? NFTs?), or how it differs from other transfer-related tools.

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

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

The input schema has 0 parameters, so schema description coverage is effectively 100%. Baseline for 0 parameters is 4. The description adds no parameter info, but none is needed.

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 'Enhanced transfer feed' is a vague noun phrase without a verb or specific resource. It does not clearly state what action the tool performs or what it returns, and it fails to distinguish itself from sibling tools like token_balances or nft_metadata.

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 usage guidance is provided. The description lacks any indication of when to use this tool versus alternatives such as 'nft_owners' or 'resolve_entity'. It does not specify context or exclusions.

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?

Adds significant behavioral context beyond annotations: resolves market, classifies bet, fans out to packs, returns evidence packet with comparison. Also explains output size control via include_raw. No contradiction with annotations (readOnlyHint, idempotentHint).

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, well-structured, every sentence adds value. Slightly longer than necessary but remains focused and 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?

Despite no output schema, the description adequately explains return value ('evidence packet plus market-vs-model comparison'). Covers complexity of multi-source data and classification. Lacks details on return structure but sufficient for agent understanding.

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 has 100% description coverage; description adds extra meaning: clarifies market formats (slug, URL, question text), enum values for depth, and default/behavior of include_raw with size implications.

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 verb 'Research' and the resource 'Polymarket bet' using Pipeworx data, and distinguishes itself from sibling tools like validate_claim by describing its comprehensive data-pulling and classification.

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 clear use cases ('should I bet on X?', 'what does the data say?', 'is there edge?') and notes it's the core demo product. Lacks explicit when-not-to-use or alternative tool recommendations, but context 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?

Annotations already declare readOnly, openWorld, idempotent. Description adds details: pulls revenue/net income/cash/debt from SEC EDGAR/XBRL for companies; adverse events, approvals, trials from FAERS/FDA for drugs. Includes citation URIs. 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?

Three sentences, front-loaded with core function. Every sentence adds value: what it does, when to use, what it returns. 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?

Covers both entity types, data sources, and return format (paired data, citations). No output schema, but description hints at structure. Could specify that result is a single object, but adequate overall.

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. Description adds meaning beyond schema: explains data sources per type and what metrics are returned. Provides examples (e.g., AAPL, MSFT; ozempic, mounjaro).

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 compares 2-5 companies or drugs side by side, with specific use cases like 'compare X and Y', 'X vs Y', etc. It differentiates from siblings; no other tool offers this paired comparison.

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

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

Explicitly states when to use (phrases like 'compare', 'vs', 'stack up', 'which is bigger') and explains it replaces 8-15 sequential calls. Does not explicitly exclude scenarios, but context is clear enough.

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 and destructiveHint false. The description adds context about returning tool names and descriptions, which is consistent and adds value beyond 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 front-loaded with the core purpose and usage guidance. While the list of example domains adds length, it aids understanding without excessive verbosity.

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 lacking an output schema, the description mentions the return type ('tool names + descriptions') and the behavioral context (top-N). This is sufficient for a discovery tool, though more detail on result ordering could help.

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%; the description restates the query parameter's purpose ('natural language description') and limit's default. It adds no new semantic value beyond the schema, earning a baseline score of 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 explicitly states the tool's purpose: 'Find tools by describing the data or task.' It provides a list of example domains and clarifies it returns top-N relevant tools, distinguishing it from sibling tools that perform specific actions.

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 clear guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This tells when to use and when not to, aiding correct selection.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. Description adds value by detailing the return payload (filings, fundamentals, patents, news, LEI) and mentions pipeworx:// citation URIs. Could mention edge cases or rate limits, 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?

Single paragraph, front-loaded with purpose. Every sentence adds information. Could be slightly more structured (e.g., bullet points for outputs) but 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?

No output schema, so description must explain return values. It clearly enumerates what is returned: SEC filings, revenue/net income/cash position, patents, news, LEI, and citation URIs. Sufficient for a complex aggregated 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 coverage 100% with descriptions. Description adds critical context: for type, only 'company' supported; for value, ticker or zero-padded CIK, and explicitly states names are not supported, directing to resolve_entity. This goes 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?

Starts with 'Get everything about a company in one call', a clear verb+resource. Distinguishes from siblings by noting it replaces 10+ pack tools across SEC EDGAR, SEC XBRL, USPTO, news, and GLEIF. Lists specific outputs: SEC filings, revenue/net income/cash position, patents, news, LEI.

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: examples like 'tell me about X', 'brief me on Tesla'. Also gives when-not-to-use: 'Names not supported — use resolve_entity first if you only have a name.' Clearly differentiates from sibling resolve_entity.

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 destructiveHint=false, informing the agent about safety. However, the description adds no further behavioral details, such as that the tool supports any method name via the 'method' parameter, or that it requires a chain. It does not disclose the generic nature beyond the name.

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?

While extremely short, the description fails to be informative. Every word should add value, but 'Generic JSON-RPC call' is redundant and vague. The tool name already implies a JSON-RPC call.

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

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

For a tool with 3 parameters, many siblings, and an output schema, the description is critically incomplete. It omits the domain (Ethereum), parameter meanings, output format, and when to prefer this over specialized tools. The agent cannot safely use this tool based on the description alone.

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?

With 0% schema description coverage, the three parameters (chain, method, params) are undocumented. The description provides no explanation of their types, constraints, or relationship to JSON-RPC calls. Examples exist but are insufficient without textual clarification.

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 'Generic JSON-RPC call' is tautological and fails to specify the tool's domain (Ethereum), its capabilities, or differentiate it from sibling tools like token_balances or token_metadata. It does not state that it sends a raw JSON-RPC request to an Ethereum node.

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 sibling tools. Given the many specific Ethereum tools, the agent needs to know that eth_call is a low-level alternative, but no usage context is given.

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 provide destructiveHint=true and readOnlyHint=false. Description adds context about clearing sensitive data, which is valuable beyond annotations. No contradictions.

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 concise sentences, front-loaded with the action. Every sentence adds value with no 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?

For a simple 1-parameter destructive tool with no output schema, the description fully covers purpose, usage guidance, and relation to siblings. Complete and actionable.

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?

Single parameter 'key' has schema description 'Memory key to delete'. Schema coverage is 100%, so the description adds no further detail. Baseline score of 3 is appropriate.

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

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

Description clearly states 'Delete a previously stored memory by key' with a specific verb and resource. It distinguishes from sibling tools like 'remember' and 'recall'.

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 context is stale, the task is done, or you want to clear sensitive data'. Also suggests pairing with related tools.

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

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

Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds behavioral details: it fetches the page, extracts title/description/key links, and emits standard markdown. No contradictions; the description enhances understanding of the tool's 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 a single well-structured paragraph that front-loads the core purpose, describes the process, and lists use cases. It is informative without being verbose. A minor improvement could be trimming redundant phrasing, 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?

The description explains the output format (single text blob for site-root/llms.txt) and the input parameters are covered by the schema. It does not address error handling or edge cases, but for a straightforward tool with no output schema, the detail provided is sufficient for an agent to use it 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% with clear descriptions for both parameters (url and max_links). The tool description does not add significant new meaning beyond the schema; it only indirectly references the parameters. Baseline score of 3 is appropriate given the schema already covers the semantics.

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

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

Clearly states the tool generates an llms.txt file for AI crawlers, specifies target users (ChatGPT, Claude, Perplexity), and lists concrete use cases. Distinguishes itself from sibling tools like ai_visibility_check and scan_competitor_ai_presence by focusing on file generation rather than visibility analysis.

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 lists three useful scenarios (client indexing, personal project drafting, competitor auditing). Provides context on when to apply the tool, though it does not explicitly state when not to use it or mention alternatives. Still, the usage guidance is clear and helpful.

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, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds no further behavioral context, but does not contradict 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 extremely concise (3 words) but sacrifices informativeness. It is front-loaded but lacks structure and detail.

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 having an output schema, the description fails to provide any context for parameter usage or tool selection among many NFT siblings. It is severely incomplete for a tool with 4 parameters.

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 0%, and the description does not explain any of the 4 parameters (chain, tokenId, contract, refresh_cache). The description adds no value beyond the bare parameter names.

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 'Single NFT metadata' indicates the tool returns metadata for one NFT, but it lacks specificity and does not distinguish from sibling tools like nft_owners or token_metadata. The purpose is clear but minimal.

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 usage guidance is provided. The description does not mention when to use this tool over alternatives, nor does it specify prerequisites or context.

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 readOnlyHint=true and destructiveHint=false, so the description's minimal statement is acceptable but adds little beyond that. It does not disclose potential pagination behavior, response size limits, or data freshness. Given annotations cover basic safety, a score of 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 extremely concise (five words) but lacks sentence structure and front-loading of key information. While brevity is valued, it sacrifices clarity on purpose and usage, earning a middling score.

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 having an output schema and few parameters, the description does not explain the output (likely list of owner addresses) or provide usage context like whether the chain parameter is required for non-Ethereum contracts. It is too sparse to be fully complete for an AI 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 0%, and the description does not explain the parameters beyond implying contract is needed and tokenId is optional. It fails to clarify the role of 'chain' (optional? default?) or what happens when tokenId is omitted. The examples in the schema provide some context, but the description should compensate more given the low coverage.

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

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

The description 'Owners of a contract/token' clearly indicates the tool returns owners for a given contract or specific token, distinguishing it from sibling tools like nfts_owned (which returns NFTs owned by a user) and nfts_for_collection (which returns NFTs for a collection). It uses a specific verb+resource pattern, though could be more explicit about the return format.

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. There is no mention of prerequisites, recommended scenarios, or when NOT to use it. For example, it doesn't suggest using nfts_owned for user-specific queries or clarify whether a chain parameter is necessary.

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, openWorldHint, idempotentHint, and destructiveHint, providing a safety profile. However, the description adds no behavioral context beyond annotations, such as pagination, rate limits, or response structure. It misses an opportunity to clarify behavior not covered by 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 extremely concise (five words), but this is under-specification rather than effective conciseness. It does not earn its place because it provides almost no information. An informative description could be concise while still conveying essential details.

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 5 parameters, an output schema, and siblings, the description is severely incomplete. It does not explain what the tool returns, how to paginate results, or how to filter. The agent has insufficient context to decide between this and similar tools or to invoke it 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 0%, so parameter descriptions are entirely missing from both schema and tool description. The description does not explain any of the five parameters (chain, limit, contract, startToken, withMetadata), leaving the agent to guess from parameter names alone. This is inadequate for correct invocation.

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 'NFTs in a collection' is vague and lacks a verb. It does not specify what operation is performed (e.g., list, retrieve). The tool name suggests it relates to NFTs for a collection, but without a clear action, its purpose is ambiguous, especially among siblings like nft_metadata and nft_owners.

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 usage context is provided. The description does not indicate when to use this tool versus siblings (nft_metadata, nft_owners, etc.). There is no mention of prerequisites, filters, or typical use cases.

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

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

The annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) already declare safety and idempotency, but the description adds no extra context about pagination, rate limits, or the structure of the returned data. Given the annotations, the bar is lower, but the description still lacks behavioral details beyond the bare minimum.

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 only 3 words, which is too brief for a 5-parameter tool. While concise, it sacrifices necessary detail. Important information about parameters and usage is omitted.

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 (5 parameters, many siblings, output schema exists), the description fails to cover filtering (contracts), pagination (page_key, page_size), or chain support. It is insufficient 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?

With 0% schema description coverage, the description must explain parameters. It only mentions 'owner' implicitly via 'address' and ignores chain, page_key, contracts, and page_size entirely. No parameter meanings or usage are provided.

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 'NFTs owned by address' clearly indicates the tool retrieves NFTs owned by a given address, but it does not differentiate from siblings like nft_owners (which may return owners for a specific NFT) or nfts_for_collection (NFTs in a collection). The verb is implied but not explicit.

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 vs alternatives (e.g., nft_metadata, nft_owners). There is no mention of suitable use cases or conditions for choosing this tool over others.

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 all false, so description carries the burden. It reveals that feedback is sent to the team, rate-limited to 5/day, and free. Could mention that it's a persistent write operation, but 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?

Five sentences, each adding unique value. Front-loaded with purpose, then usage guidance, then constraints. 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 the simple nature of a feedback tool with no output schema, the description is complete. It covers purpose, usage, constraints, and formatting. No 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?

Input schema has 100% coverage with descriptions for each parameter. The description adds extra guidance on how to write the message (be specific, don't paste prompt), which adds 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?

The description clearly states the tool's purpose: providing feedback to the Pipeworx team (bug, feature, data_gap, praise). It distinguishes itself from sibling tools by specifying when to use it and how to format 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?

Provides explicit when-to-use scenarios (bug, missing feature, praise) and what not to do (don't paste user prompt). Also mentions rate limits and that it's free/quota 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?

Annotations already cover idempotency, read-only, non-destructive. Description adds valuable context: caching behavior (5min-1h), data source (CF analytics-engine), and no PII. 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?

Three well-structured sentences, each serving a purpose: what it does, use cases, and technical detail. No 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?

Low complexity tool with no output schema, but description adequately covers return value (top tools/packs/volume). Could hint at output format (e.g., list/object) but not necessary.

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

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

Only one parameter (window) with 100% schema coverage. Description adds semantics beyond enum values by explaining 'shorter windows surface what's hot; longer show steady-state'. Adds value.

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 tools, packs, and call volume over a window. Unique among siblings with a specific resource (trending signals).

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?

Lists three explicit use cases: discovering hot data sources, confirming canonical choice, and seeing alignment. Provides context for when to use without mentioning when not, but hints at non-PII nature.

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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety profile. Description adds behavioral detail about searching, grouping markets, checking monotonicity, and returning ranked opportunities with reasoning, which goes beyond annotations and helps the agent understand the tool's logic.

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

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

Description is a well-structured single paragraph that front-loads the purpose, explains modes with examples, and concludes with what the tool returns. Every sentence provides essential information with 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 no output schema, the description adequately explains return values (ranked opportunities with suggested direction + reasoning). It covers both modes, the logic behind cross-event mode, and the tool's purpose. Annotations cover safety and idempotency, leaving no significant 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?

All two parameters have schema descriptions (coverage 100%), and the description adds significant meaning: categorizes each parameter as 'single-event mode' or 'cross-event mode', provides examples, and explains the behavior when each is used. This enhances 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?

Description clearly states the tool finds arbitrage opportunities on Polymarket by checking monotonicity violations. It specifies two modes ('event' and 'topic') with distinct use cases, differentiating from siblings like 'polymarket_edges' which focus on different analyses.

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 describes when to use each mode: single-event mode for a specific event slug, cross-event mode for topic searches. Provides examples and explains why cross-event mode catches cases missed by single-event mode (e.g., cutoff dates as separate events). Offers clear guidance on when not to use single-event mode.

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?

The description extensively explains the internal model (lognormal from FRED, live coinpaprika price), data fetching strategy (fetches per asset once), and assumptions about slippage and fees. This adds significant behavioral context beyond the idempotent/read-only annotations, with 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?

The description is concise (6-7 sentences) and well-structured: purpose, method, use case, and parameter context. 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, the description sufficiently explains return type (top N ranked by edge magnitude with trade direction). It covers domain, data sources, model, and parameter rationale, making it complete for the tool's complexity.

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 for all 6 parameters, providing detailed semantics. The tool description adds minimal parameter-specific detail beyond context about slippage and min_kelly filtering, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool scans high-volume Polymarket markets to find where Pipeworx data disagrees with market price, with a specific verb and resource. However, it does not explicitly distinguish from siblings like polymarket_arbitrage, which may have overlapping functionality.

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 frames the tool for discovering betting opportunities ('what should I bet on today') and mentions it returns top N edges with trade direction. It provides clear context but does not explicitly state when not to use it or mention 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?

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent. The description adds significant context: it returns prices and spreads, explains spread calculation as 'Kalshi − Polymarket in percentage points', mentions typical 2-25pp difference, and notes the delta as an arb signal.

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 6 sentences, well-structured with separate mode explanations. It is appropriately sized for the complexity and front-loads the core purpose.

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

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

Despite no output schema, the description fully explains return values: leg-by-leg prices in 0-1 and spread where outcomes match. It covers all necessary aspects for a spread calculator 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 coverage is 100%. The description adds meaning by explaining the two modes and the override behavior (e.g., 'Overrides the topic-mapped... side'), which goes beyond the schema's basic descriptions.

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

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

The description clearly states it is a cross-venue spread tool between Kalshi and Polymarket for the same question, with specific modes ('topic' shortcuts and explicit tickers). This distinguishes it from siblings like 'polymarket_arbitrage' and 'polymarket_edges'.

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: 'topic' for pre-mapped macros and explicit tickers for custom pairings. While it doesn't explicitly mention when not to use or alternatives, the context is clear and covers the main use cases.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds scoping details and that it avoids re-deriving context. No contradictions. Adds meaningful context beyond 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?

Three sentences, each serves a distinct purpose: core function, usage examples and scoping, pairing with siblings. No redundancy, highly 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?

For a simple retrieval tool with one optional parameter, the description covers purpose, usage, scoping, and relationship to siblings. Annotations cover safety. No output schema needed.

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 the parameter 'key' described as 'Memory key to retrieve (omit to list all keys)'. The description does not add new information beyond the schema, 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 value saved via remember or lists all keys when omitted. It identifies the resource (saved values) and verb (retrieve/list), and distinguishes from siblings 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?

Explicitly states when to use (look up context stored earlier like ticker or address) and when to omit key to list. Mentions pairing with remember and forget, and scoping to identifier.

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 mark it as read-only, open-world, idempotent, and non-destructive. The description adds valuable behavioral details: parallel fan-out to three sources, return format (structured changes + count + URIs), and input format flexibility. No contradictions.

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 paragraph that efficiently conveys purpose, usage hints, technical details, and return format without redundancy. 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?

Despite no output schema, the description explains the return structure (structured changes + total_changes count + URIs) and the fan-out mechanism. It is fully informative for an AI agent to understand what to 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?

Schema description coverage is 100%, and the description enriches parameter meanings, e.g., explaining that 'since' accepts ISO dates or relative shorthand like '7d', and that 'value' can be ticker or CIK. This adds context 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 retrieves recent changes for a company, with specific examples like 'what's happening with X?' and mentions it fans out to multiple sources (SEC, GDELT, USPTO). This distinguishes it from siblings like 'entity_profile' and 'compare_entities'.

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

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

Explicitly provides usage scenarios with example queries, but does not include explicit when-not-to-use or alternative tools. The examples adequately guide the agent, earning a 4.

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 indicate idempotent and non-destructive. Description adds scoping by identifier, persistence (24 hours for anonymous, persistent for authenticated), and implies mutation (save). No contradictions.

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 sentences, front-loaded with purpose, efficient and clear, no 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?

For a simple tool with full schema and annotations, description covers purpose, usage, behavioral details, and sibling interactions. No gaps.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds example key formats but does not significantly extend meaning beyond schema. Baseline 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?

Clearly states 'Save data the agent will need to reuse later', specifying verb (save), resource (data), and differentiates from siblings recall 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?

Explicitly states when to use: 'when you discover something worth carrying forward' and provides examples. Mentions pairing with recall/forget and persistence details.

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?

The description complements the annotations (readOnlyHint, idempotentHint) by explaining that it returns IDs plus pipeworx:// citation URIs, and does not contradict any annotation. The behavioral traits are well-addressed beyond the structured metadata.

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 well-structured: it starts with the core purpose, followed by usage guidance, examples, return values, and a final note on efficiency. 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 tool's complexity (resolving multiple entity types to multiple ID systems), the description provides complete context: what it does, when to use, what IDs to expect, and what it returns (including citation URIs). No output schema is present, but the description sufficiently covers return expectations.

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 enhances the parameters with examples (e.g., 'Apple' → AAPL / CIK 0000320193) and clarifies acceptable values for company and drug, adding significant meaning 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: looking up canonical/official identifiers for companies or drugs. It specifies the types of identifiers (CIK, ticker, RxCUI, LEI) and gives concrete examples, making it distinct 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?

The description explicitly advises when to use this tool: when a user mentions a name and you need official identifiers required by other tools. It also instructs to use it before calling other tools and notes it replaces 2-3 lookup calls, providing clear 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?

Annotations indicate readOnly, idempotent, openWorld, not destructive. Description adds process details (probes each entity, ranks) and output structure (score, confidence, signal density), enhancing transparency beyond 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?

Three sentences, front-loaded with purpose, no wasted words. Each sentence provides essential information succinctly.

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 complexity and no output schema, description explains process, result format, and use case adequately. Could mention entity count limits 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 coverage is 100% with descriptions. Description adds value by explaining that first entity is treated as subject and rest as competitors, and implies model/API usage context, going beyond schema details.

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

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

Description clearly states it compares AI visibility across multiple entities, uses ai_visibility_check for probing, and ranks results. It distinguishes from sibling 'ai_visibility_check' by emphasizing side-by-side comparison and multiple 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?

Provides concrete use case ('competitive AI-marketing audits') and example question. Implies when to use, but does not explicitly mention when not to use or alternatives for single entity check.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no additional context about what the tool does (e.g., returns a number, how allowance is calculated). It relies entirely on annotations for safety profile but does not explain behavioral nuances.

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 extremely concise (a single phrase), which is efficient but at the cost of informativeness. It is front-loaded but lacks necessary details, making it barely adequate. No wasted words, but under-specified.

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 4 parameters, an output schema, and 17+ sibling tools, the description is severely incomplete. It does not explain the output format, return values, or how the tool interacts with the blockchain. An agent would lack context to use it 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 description coverage is 0%, meaning the description does not explain any parameter (chain, owner, spender, contract). With low coverage, the description must compensate, but it only provides the generic phrase 'ERC-20 allowance'. This fails to add meaning 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 'ERC-20 allowance' indicates the tool relates to ERC-20 allowances, which aligns with the tool name. However, it does not specify whether it queries, sets, or checks allowances, nor does it distinguish from siblings like token_balances. The meaning is somewhat clear but lacks specificity.

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 (e.g., token_balances, token_metadata). There is no mention of prerequisites, contexts, or conditions where the tool is appropriate. The description provides no usage direction.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond what is implied by the name and annotations, such as rate limits, data freshness, or side effects.

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 extremely concise at two words, which is efficient but lacks necessary detail. It is front-loaded but at the expense of completeness. The examples in the schema partially compensate, but the description itself is too sparse.

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 an output schema, explanation of return values is not required. However, the description fails to mention optional parameters (chain, contracts) and the behavior when contracts are omitted. This leaves gaps for the agent.

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

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

Schema description coverage is 0%, and the description does not explain the parameters (chain, address, contracts) beyond the schema examples. The examples are helpful but not part of the description itself. No additional meaning is provided.

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 'ERC-20 balances.' clearly states the tool's function of retrieving ERC-20 token balances. However, it does not differentiate from sibling tools like 'token_metadata' or 'token_allowance', and it could be more specific (e.g., mentioning filtering by address or contracts).

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

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

No guidance is provided on when to use this tool versus alternatives like 'asset_transfers' or 'nft_owners'. There is no mention of prerequisites, limitations, or typical use cases.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and no destructiveness. The description adds no new behavioral context (e.g., caching, rate limits, or response structure beyond what the output schema provides).

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 extremely concise (3 words) but at the expense of completeness. It is front-loaded but too minimal to be helpful; every word earns its place but fails to convey 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?

Given the simple tool (2 parameters, 1 required) and existence of an output schema, the description still misses key context about parameters. The example in the schema helps but is not part of the description, leaving the agent underinformed.

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?

With 0% schema description coverage, the description must explain parameters, but it does not. 'ERC-20 metadata' gives no hint about the 'chain' or 'contract' parameters, leaving the agent to infer from the schema's example (which is not part of the 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 'ERC-20 metadata' clearly indicates the resource (ERC-20 tokens) and the action (fetching metadata). It distinguishes from sibling tools like token_balances (balance query) and nft_metadata (non-fungible tokens). However, it lacks specificity on what metadata is returned.

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 like token_allowance or token_balances. The description does not mention conditions, prerequisites, or exclusions.

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 read-only, idempotent, and non-destructive behavior. The description adds significant behavioral details: it returns a verdict (confirmed, approximately_correct, etc.), extracted structured form, actual value with citation, and percent delta. It also notes the tool replaces 4-6 sequential calls, demonstrating efficiency without 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?

The description is concise (5 sentences) and front-loaded with purpose and usage guidance. Every sentence adds value without unnecessary detail.

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

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

Given one parameter and no output schema, the description adequately covers the tool's purpose, domain, return format (verdict types, citation, delta), and usage context. It could be more complete by explaining approximate_correctness or limitations (e.g., only US companies), but it is largely 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% for the single 'claim' parameter, with a clear description and examples. The tool description reinforces this by repeating examples but adds no additional semantic meaning 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 function: fact-checking natural-language factual claims against authoritative sources. It specifies the domain (company financial claims for US public companies) and gives example queries. This uniquely distinguishes it from siblings like 'bet_research' or 'compare_entities'.

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

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

The description explicitly says when to use the tool ('when an agent needs to check whether something a user said is true') and provides example prompt patterns. However, it does not explicitly state when not to use it or mention alternative tools for other claim types.

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