crossref

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

Adds significant context beyond annotations: describes per-model return structure {score, confidence, signals, raw_response}+combined view, and that Anthropic probing requires user-provided API key. No contradiction with annotations.

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

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

Four sentences, front-loaded with core action and return type, no redundant phrasing. Every sentence adds unique 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?

With no output schema, the description adequately describes return structure. All 4 parameters are covered, and the tool's behavior is well-specified for a probing 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?

All parameters have schema descriptions (100% coverage). The description adds value by explaining default model, key usage, and context purpose for disambiguation.

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 'probe', resource 'LLMs', and output 'score visibility (0-100) per model'. It distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on general brand/product visibility audits.

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 mentions use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and default model behavior. Lacks explicit when-not-to-use or alternatives, but context suffices.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it picks the right tool, fills arguments automatically, and returns results. However, it lacks details on limitations like rate limits, error handling, or data source constraints, which would be helpful for a tool with such broad functionality.

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 functionality, uses efficient sentences with zero waste, and includes illustrative examples that enhance understanding without verbosity. Every sentence earns its place by clarifying purpose and usage.

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

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

Given the tool's complexity (natural language querying with automatic tool selection) and lack of annotations or output schema, the description is mostly complete but could benefit from more on behavioral limits or response formats. It adequately covers purpose and usage, though some operational details are omitted.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'question' as a natural language string. The description adds minimal value beyond this by reinforcing it's a 'question or request in plain English', but doesn't provide additional syntax or format details, meeting the baseline for high 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 clearly states the tool's purpose with specific verbs ('ask a question', 'get an answer') and resources ('best available data source'), and distinguishes it from siblings by emphasizing its natural language interface versus needing to browse tools or learn schemas. It provides concrete examples that illustrate its unique 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?

It explicitly states when to use this tool ('just describe what you need') and when not to ('no need to browse tools or learn schemas'), offering clear alternatives by implication (use other tools for structured queries). The examples reinforce appropriate usage contexts.

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 readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'research'. The description adds rich behavioral details: resolving market, classifying bet type, fanning out to appropriate data packs, and returning a comparison. No contradiction with annotations.

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

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

The description is front-loaded with the core function and progressively adds detail. Every sentence provides value, from input formats to output components. While a bit lengthy, the complexity of the tool justifies the length.

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 thoroughly explains the return format (evidence packet + market-vs-model comparison) and the bet classification categories. It covers inputs, processing (fan-out), and outputs comprehensively 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 coverage is 100% and already describes both parameters: 'market' (slug/URL/text) and 'depth' (quick vs thorough with default). The description reiterates this but adds no new information beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: researching a Polymarket bet by pulling Pipeworx data. It specifies input types (slug, URL, question text) and outputs (evidence packet, comparison). It distinguishes itself from siblings by noting that this tool integrates discovery of relevant packs, improving conversion over doing it manually.

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

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

The description provides explicit use cases: 'should I bet on X?', 'what does the data say?', 'is there edge?'. It implies when to use by contrasting with sibling tools (agents using this convert better). However, it does not explicitly state when not to use, but the given usage scenarios are 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?

No annotations provided, so description carries full burden. It mentions returns paired data and URIs, but does not explicitly state it is read-only or disclose potential side effects. Adequate but not fully 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?

Description is four sentences, front-loaded with main purpose, no redundant information. 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 no output schema, description adequately explains return data for both types and mentions URIs. For a simple tool with 2 params, it is mostly complete, though missing error handling or auth details.

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%, baseline 3. Description adds value by explaining the return fields per type (e.g., revenue for company, adverse-event counts for drug), which helps agent understand parameter impact.

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 2-5 entities side by side, specifies two types (company/drug) and the data returned for each, and distinguishes from siblings by mentioning it replaces 8-15 sequential calls.

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

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

Description explicitly states it replaces multiple sequential agent calls, indicating when to use it, but does not provide explicit when-not-to-use or alternatives among siblings.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool searches by natural language description and returns ranked results ('most relevant'). However, it doesn't mention limitations like rate limits, authentication requirements, or error conditions that would be important for a 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?

The description is perfectly concise and front-loaded. The first sentence states the core functionality, the second explains the return value, and the third provides crucial usage guidance. Every sentence earns its place with no wasted words.

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

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

Given the tool's moderate complexity (search functionality with 2 parameters) and lack of annotations/output schema, the description does well by explaining the search behavior and providing strong usage guidance. However, it could better address behavioral aspects like result format details or error handling to be fully 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%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema - it implies the 'query' parameter accepts natural language descriptions but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('search', 'returns') and resources ('Pipeworx tool catalog', 'most relevant tools with names and descriptions'). It distinguishes itself from sibling tools by focusing on tool discovery rather than retrieving specific entities like journals, works, or workspaces.

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

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

The description provides explicit usage guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear context for when to use this tool versus alternatives, including a quantitative threshold (500+ tools) and a specific scenario (finding tools for a task).

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

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

No annotations provided, so description carries full burden. Describes what is returned (citation URIs), data sources, and bundling benefit. Mentions speed constraint for federal contracts. Lacks details on errors or auth, but adequate for a profile tool.

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

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

3-4 sentences, front-loaded with purpose. Every sentence provides unique information. 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?

No output schema, but description mentions returns pipeworx:// citation URIs. Covers main content and alternative usage. Missing error conditions and detailed structure, but sufficient for common use.

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

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

Schema coverage is 100%, baseline 3. Description adds extra meaning: value can be ticker or zero-padded CIK, names not supported, and directs to resolve_entity. 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?

Description clearly states it returns a full profile of an entity across multiple data sources (SEC, XBRL, patents, news, LEI). Specifies supported type and content, and distinguishes from siblings by noting it replaces 10-15 sequential calls.

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

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

Explicitly says when to use (full profile) and when not (federal contracts -> use usa_recipient_profile). Also implies prerequisite: use resolve_entity if only a name is available.

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

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

No annotations are provided, so the description carries full burden. It states 'Delete' which implies a destructive mutation, but doesn't disclose whether this is permanent, reversible, requires specific permissions, or has side effects. For a destructive operation with zero annotation coverage, this is a significant gap in 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?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

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

For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after deletion (e.g., confirmation, error handling), the scope of 'stored memory', or how this interacts with sibling tools. More context is needed given the mutation nature.

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

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

Schema description coverage is 100%, with the single parameter 'key' documented as 'Memory key to delete'. The description adds no additional meaning beyond what the schema provides, such as key format or examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the action ('Delete') and resource ('a stored memory by key'), providing specific verb+resource pairing. However, it doesn't distinguish this tool from potential siblings like 'recall' or 'remember' that might also manipulate memories, missing explicit differentiation.

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. With siblings like 'recall' (likely for retrieving memories) and 'remember' (likely for storing memories), the description lacks context about when deletion is appropriate or what prerequisites might exist.

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 the process (fetches page, extracts title/description/key links, emits markdown format), which aligns with annotations (readOnlyHint=true, idempotentHint=true). Description adds helpful detail beyond annotations 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?

Single, well-structured paragraph with purpose upfront, followed by process and use cases. No wasted words; every sentence adds value.

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

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

Given the tool's simplicity, the description fully covers purpose, behavior, and output. No output schema is needed as description states 'single text blob'. Annotations already convey safety and idempotency.

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 100% of parameters with descriptions. The tool description does not add new meaning beyond schema; it only restates the purpose of 'url' and 'max_links' without further 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 the tool generates an llms.txt file for AI crawlers, specifying the action (generate), resource (llms.txt file for a URL), and purpose (clean indexing). It distinguishes itself from siblings by highlighting its specific output 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?

Description provides three concrete use cases (client indexing, own project drafting, competitor auditing), offering clear context. However, it does not explicitly mention when not to use or alternative tools, leaving a minor gap.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format (title, authors, DOI, publication date) and the limit of 5 most recent works, which is useful. However, it lacks details on error handling, rate limits, authentication needs, or whether it's a read-only operation, leaving gaps for a tool with no annotation support.

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 sentence that efficiently conveys the tool's purpose, input, and output without any wasted words. It is front-loaded with the core functionality, making it easy for an agent to parse quickly.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is reasonably complete for basic use. It covers what the tool does and what it returns. However, without annotations or an output schema, it lacks details on behavioral traits like error conditions or response structure, which could hinder agent reliability.

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

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

Schema description coverage is 100%, so the input schema already documents the 'issn' parameter with an example. The description adds context by specifying it's for a journal and that it retrieves recent works, but does not provide additional semantic details beyond what the schema offers, such as format constraints or edge cases.

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

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

The description clearly states the specific action ('Get'), resource ('5 most recent works published in a journal'), and scope ('by its ISSN'), with distinct output details. It differentiates from sibling tools like 'get_work' (likely for individual works) and 'search_works' (likely broader searches) by focusing on journal-specific recent publications.

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

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

The description implies usage when needing recent works from a specific journal via ISSN, but it does not explicitly state when to use this tool versus alternatives like 'search_works' or 'get_work'. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return data (title, authors, etc.) and implies a read-only operation, but lacks details on error handling, rate limits, authentication needs, or performance characteristics. It adds basic context but misses deeper behavioral traits.

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

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

The description is front-loaded with the core purpose in the first clause, followed by a concise list of return values. It uses two efficient sentences with zero waste, making it easy to scan and understand quickly without unnecessary elaboration.

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

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

Given the tool's low complexity (single required parameter) and no output schema, the description adequately covers the purpose and return data. However, it lacks information on error cases (e.g., invalid DOI), response format details, or integration with sibling tools, leaving some contextual gaps for an agent to handle edge cases.

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

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

Schema description coverage is 100%, with the parameter 'doi' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., no extra examples or constraints), so it meets the baseline for high schema coverage without compensating further.

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

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

The description clearly states the specific action ('Get full metadata'), resource ('academic work'), and identifier ('by its DOI'), distinguishing it from sibling tools like 'get_journal' (journal-level) and 'search_works' (search multiple). It precisely defines what the tool does without being vague or tautological.

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 implicitly indicates usage context by specifying 'by its DOI', suggesting this tool is for retrieving metadata when a DOI is known. However, it does not explicitly state when to use it versus alternatives like 'search_works' (for broader searches) or 'get_journal', nor does it provide exclusions or prerequisites, leaving some guidance gaps.

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

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

No annotations, so description carries full burden. It discloses rate limit (5/day) and privacy instruction (omit prompts). Does not mention response/acknowledgment but is sufficient for a feedback tool.

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

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

Four sentences, no wasted words. Front-loaded with primary purpose. Every sentence contributes (purpose, usage, privacy, rate limit).

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 3-param tool with no output schema, the description covers all essential aspects: what it does, how to use it, what not to include, and constraints. Complete for its purpose.

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

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

Schema coverage is 100% (baseline 3). Description adds value by advising 'describe what you tried in terms of Pipeworx tools/data' and imposing a 2000-char limit, supplementing schema descriptions.

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

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

Description clearly states 'Send feedback to the Pipeworx team' and lists specific use cases (bug, feature, data_gap, praise). It distinguishes from sibling tools by its unique feedback purpose.

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

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

Explicitly says when to use (feedback types) and includes a clear exclusion (do not include user prompt verbatim) plus rate limit. Lacks explicit comparison to alternatives, but context suggests this tool is the only feedback channel.

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?

Beyond annotations (readOnly, idempotent, non-destructive), the description adds caching intervals, data source (CF analytics-engine), PII-free guarantee, and self-aggregating nature. No contradiction with annotations.

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

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

The description is front-loaded with purpose and uses bullet points. Every sentence adds value, though slightly verbose; could be tighter.

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

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

With a simple input schema (one param, no output schema) and good annotations, the description covers return contents, caching, data derivation, and privacy, making it sufficiently complete.

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

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

Schema coverage is 100% with an enum description. The description adds marginal value by explaining trade-offs of shorter vs. longer windows, but the 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 that the tool returns top tools, top packs, and total call volume over a recent window, specifying verb+resource (+scope). It distinguishes from siblings by focusing on trending usage rather than general discovery or search.

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 lists three specific use cases (discovering hot data sources, confirming canonical tool, seeing alignment). It provides clear context but does not explicitly state when not to use the tool or name alternative siblings.

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

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

Annotations indicate read-only, open-world, non-destructive behavior. The description adds that results include ranked opportunities with trade direction and reasoning, and cross-event mode searches for related markets. No contradictions. Could mention data staleness or rate limits, but overall adequate.

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

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

The description is a single, well-organized paragraph. It starts with the core purpose, then explains each mode with examples, and ends with return value. Every sentence adds value; no wasted words.

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

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

The description covers the main functionality and return format. It doesn't mention error cases or prerequisites (e.g., internet access), but given the complexity and good annotations, it's reasonably complete. Might benefit from a note on data freshness.

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 both parameters are described in the schema. The description adds context by linking each parameter to its mode (event slug vs topic seed), which helps the agent understand how to choose. No nested objects or enums.

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

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

The description clearly states the tool finds arbitrage opportunities by checking monotonicity violations. It specifies two distinct modes (event and topic) with concrete examples, making it easy to understand what the tool does and distinguishing it from siblings like validate_claim.

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

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

The description provides explicit guidance on when to use each mode: event mode for a single event's child markets, topic mode for cross-event searches. It explains why topic mode is needed for cases where events are split by cutoff dates, giving clear usage 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. The description adds valuable behavioral context: it uses a lognormal model from FRED and coinpaprika data, groups by asset, fetches price history once, and ranks by edge magnitude. It explains the process and output clearly without contradicting 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 comprehensive and well-structured: a concise summary sentence, followed by methodology details, output description, and use case. It is slightly lengthy but every sentence adds value, and it is front-loaded with key 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?

Despite no output schema, the description comprehensively covers what is returned (top N ranked by edge magnitude with suggested trade direction) and the overall process. It fully explains the tool's function, inputs, and output for agent invocation.

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 meaning: it explains the purpose of each parameter (limit for top N, window for volume filter, min_edge_pp for minimum edge), provides defaults, and notes the max for limit (25). This goes beyond the schema descriptions.

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

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

The description clearly states the tool scans high-volume Polymarket markets to find where Pipeworx data disagrees with market price, returning top edges. It distinguishes itself from sibling tools like polymarket_arbitrage and bet_research by focusing on edge discovery for betting opportunities.

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 it is built for the 'what should I bet on today' question and helps agents/users discover opportunities without manual paging. It implies when to use but does not explicitly state when not to use, though the context is clear.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds behavioral context: the typical 2-25pp spread as an arbitrage signal, and that it returns leg-by-leg prices and spreads in percentage points. 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 moderately long but well-structured: purpose, arb signal, modes, output format. Every sentence adds value. Could be slightly trimmed, but overall efficient.

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

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

Given no output schema, the description fully explains the return format (prices 0-1, spread in %). It covers both modes and provides enough context for an AI to invoke correctly. 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?

Schema coverage is 100%, but description adds value by explaining the two modes and giving example values (e.g., 'KXFED-26OCT'). It clarifies that explicit tickers override topic mapping, which is not in 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 calculates the cross-venue spread between Kalshi and Polymarket, distinguishing it from siblings like polymarket_arbitrage or compare_entities. Specific verb 'calculate spread' and resource 'cross-venue' make intent 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 explicitly explains two modes (topic shortcuts vs explicit tickers) with examples. It doesn't explicitly say when not to use it, but the context is clear. A brief note on when to prefer siblings would raise to 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's dual behavior (retrieve by key or list all) and persistence across sessions ('saved earlier in the session or in previous sessions'). However, it doesn't mention potential limitations like maximum memory size, retrieval time, or error conditions when keys don't exist.

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 perfectly concise with two sentences that each serve distinct purposes: the first explains functionality, the second provides usage context. There is zero wasted language, and the most important information (the dual retrieve/list behavior) is front-loaded.

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 (dual functionality, session persistence) and no annotations or output schema, the description does well by explaining both retrieval modes and cross-session persistence. However, it doesn't describe the format of returned memories or potential error cases, leaving some gaps for a tool that handles stored data.

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

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

The schema has 100% description coverage, so the baseline is 3. The description adds meaningful context by explaining the semantic effect of omitting the key parameter ('omit to list all keys'), which clarifies the tool's dual functionality beyond what the schema alone provides. This elevates the score above baseline.

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

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

The description clearly states the tool's purpose with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes from siblings like 'remember' (store) and 'forget' (delete) by focusing on retrieval operations. The description goes beyond the name 'recall' to explain what is being recalled.

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

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

The description provides explicit usage guidance: 'Use this to retrieve context you saved earlier in the session or in previous sessions.' It also explains when to omit the key parameter ('omit key to list all keys'), which directly addresses the tool's dual functionality. This gives clear context for when to use this tool versus alternatives like 'search_works' or 'get_journal'.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that the tool fans out to multiple sources in parallel, accepts ISO/relative dates, and returns structured changes plus total_changes count and pipeworx:// URIs. This gives a solid understanding of behavior, though it omits details like rate limits, error handling, or authentication requirements.

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

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

The description is highly concise: 4 sentences that front-load the core purpose, then add detail on data sources, date format, and return structure. Every sentence adds value without redundancy or 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?

Although there is no output schema, the description adequately explains what is returned (structured changes, total_changes, pipeworx:// URIs). All parameters are thoroughly documented in both schema and description. The tool's moderate complexity (multiple sources, multiple date formats) is fully addressed, leaving no obvious gaps for the AI agent to use 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?

Schema coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds meaningful context: it explains that 'type' currently only supports 'company', that 'since' can be ISO or relative (with specific examples like '7d', '1y'), and that 'value' can be a ticker or zero-padded CIK. This extra detail enhances the schema definitions.

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: 'What's new about an entity since a given point in time.' It specifies the supported entity type ('company') and the data sources it fans out to (SEC EDGAR, GDELT, USPTO), making it distinct from sibling tools like entity_profile or compare_entities which provide static profiles or comparisons rather than temporal change monitoring.

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?

Explicit usage guidance is provided: 'Use for brief me on what happened with X or change-monitoring workflows.' This gives clear context for when to invoke the tool. The description also explains the accepted date formats and examples ('ISO date or relative'), but does not explicitly state when not to use it or mention specific alternatives beyond what is implied by sibling tool names.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool performs a write operation ('Store'), specifies persistence characteristics ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), and implies session-scoped storage. It does not cover aspects like error conditions or performance limits, but adds substantial value beyond the basic 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?

The description is efficiently structured in two sentences: the first states the core purpose with examples, and the second adds critical behavioral context about persistence. Every phrase earns its place, with no redundant or vague language, making it front-loaded and highly concise.

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

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

For a tool with 2 parameters, 100% schema coverage, no output schema, and no annotations, the description is largely complete. It covers the tool's purpose, usage context, and key behavioral traits (persistence rules). However, it lacks details on return values or error handling, which would be beneficial given the absence of an output schema, slightly limiting completeness.

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

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

Schema description coverage is 100%, with both parameters ('key' and 'value') well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain key constraints or value formatting). Given the high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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

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

The description clearly states the specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'recall' (likely retrieval) and 'forget' (likely deletion). It provides concrete examples of what can be stored ('intermediate findings, user preferences, or context across tool calls'), 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 explicitly states when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), providing clear context for its application. However, it does not mention when not to use it or name specific alternatives among siblings (e.g., how it differs from 'recall' or 'forget'), which prevents a perfect score.

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

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

No annotations provided, so description carries full burden. It discloses supported type, input formats, and return fields, but omits error handling, authentication needs, or behavior on multiple matches.

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: two sentences plus a version note. Every sentence adds value with no redundancy. Front-loaded with 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?

For a simple lookup tool with no output schema, the description covers purpose, inputs, and return fields. Missing details on edge cases, but generally 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% coverage with clear descriptions. The description adds examples and output context, but does not significantly enhance parameter 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 resolves an entity to canonical IDs across Pipeworx data sources, specifying supported type (company) and examples. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous.

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

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

The description implies use when needing consolidated entity resolution ('in a single call', 'replaces 2–3 lookup calls'), but lacks explicit guidance on when not to use or alternatives.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds that the tool probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with specific fields (score, confidence, signal density). This goes beyond annotations by explaining the internal logic and output structure. No contradictions detected.

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

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

The description is two sentences long, front-loaded with the core purpose, followed by a relatable use case. Every word adds value; there is no redundancy or filler. It achieves maximum conciseness while conveying necessary 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 no output schema, the description partially covers the return structure by mentioning a ranked list with score, confidence, and signal density. However, it does not specify the exact format (e.g., object fields, ordering direction, or whether it includes entity names). Error handling or performance implications are also omitted. The complexity is moderate (4 params, no enums, no nesting), so the description is adequate but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that the first entity in the 'entities' array is treated as the subject, that 'context' disambiguates common names, and that 'models' includes a free default and requires an API key for Anthropic. This enhances the schema descriptions, providing practical guidance for parameter use.

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 AI visibility across multiple entities side-by-side, with a specific verb ('compare') and resource ('AI visibility'). It distinguishes from sibling tools like ai_visibility_check by mentioning it probes each entity and ranks them. The second sentence provides a concrete use case, making the purpose unmistakable.

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 the tool is useful for competitive AI-marketing audits and implies it should be used when comparing multiple brands. It notes that the first entity is treated as the 'subject' for narrative, guiding usage. However, it does not explicitly state when NOT to use it (e.g., for single-entity checks) or list alternatives, though the sibling tool ai_visibility_check covers single-entity 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?

No annotations are provided, so the description carries full burden. It mentions the return fields (title, authors, etc.) but doesn't disclose important behavioral traits like rate limits, authentication needs, pagination, error handling, or whether this is a read-only operation. The description adds minimal behavioral context beyond basic functionality.

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 sentence that efficiently conveys purpose, method, and return values. Every element earns its place with zero waste, making it appropriately sized and front-loaded.

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

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

Given no annotations and no output schema, the description provides basic functionality and return fields but lacks completeness for a search tool. It doesn't cover error cases, result ordering, or detailed behavioral context, leaving gaps in understanding how the tool behaves in practice.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of query syntax beyond the schema's example, no clarification on 'limit' behavior). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Search academic works'), the resource ('Crossref index'), the method ('by keyword'), and distinguishes from sibling tools by specifying it's for searching rather than retrieving specific items like 'get_journal' or 'get_work'.

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

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

The description implies usage context (searching academic works by keyword) but doesn't explicitly state when to use this tool versus the sibling tools 'get_journal' or 'get_work'. No guidance on exclusions or alternatives is provided.

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?

Describes return values (verdict, extracted form, actual value, citation, percent delta) and supported data sources (SEC EDGAR + XBRL). Since no annotations exist, it carries full burden; could mention handling of unsupported claim types explicitly.

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?

Concise description (4 sentences) with front-loaded purpose, no redundant words. Every sentence adds meaningful 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?

Despite no output schema, the description explains return values comprehensively. Covers claim type, sources, and tool role. Adequate for a single-parameter tool with clear domain focus.

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

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

The only parameter 'claim' is fully described in schema, and the description adds substantial context: specifies natural-language format, provides examples, and clarifies the domain scope. Baseline 3 is elevated to 5 for this added 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?

Clearly states the tool fact-checks natural-language claims against authoritative sources, specifies the domain (company-financial for US public companies), and distinguishes itself from siblings by replacing 4-6 sequential agent calls.

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

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

Provides clear context on when to use (fact-checking claims), notes it replaces sequential calls, but does not explicitly state when not to use or compare with alternatives like ask_pipeworx or search_works.

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