Jargon Translator

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by explaining the return structure (per-model {score, confidence, signals, raw_response} + combined view) and the cost implication of using Anthropic (BYO key, direct payment). No contradictions with annotations.

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

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

The description is a single paragraph of four sentences, front-loaded with the primary action and then detailing specifics. Every sentence contributes meaningful information without redundancy. Highly concise and well-structured.

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

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

Given the tool's complexity (4 parameters, no output schema), the description covers purpose, return format, use cases, and cost implications. It does not explain the 'signals' field in the return or potential rate limits, but overall it is fairly complete and informative.

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), so baseline is 3. The description adds value by explaining which model is default and clarifying that _apiKey is needed only for Anthropic. It also gives example values for the entity parameter, enhancing understanding beyond the schema.

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

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

The description clearly states the tool probes LLMs about a business/brand/product/topic and returns a visibility score per model. It specifies the default model and the optional Anthropic model with BYO key. Examples of use cases (AI-marketing audits, pre-launch brand checks) further clarify purpose and distinguish it from siblings like scan_competitor_ai_presence.

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 context: AI-marketing audits, pre-launch brand checks, competitive monitoring. It also explains prerequisites (Anthropic API key needed for that model). However, it does not explicitly state when not to use this tool or compare directly to alternatives like scan_competitor_ai_presence, which slightly lowers the 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?

The description discloses key behavioral traits: it picks the right tool, fills arguments, and returns results. Since no annotations are provided, the description carries full burden, and it does a good job explaining what the tool does internally. However, it doesn't mention any potential limitations, rate limits, or error conditions.

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

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

The description is concise (three sentences) and front-loaded with the core purpose. Every sentence adds value: first sentence states function, second explains how it works, third provides examples. 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 has only one required parameter and no output schema, the description adequately covers what the agent needs to know: it's a natural language query interface. It is complete enough for a simple tool, though it could mention that the answer is returned as text.

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 baseline is 3. The description adds meaning by clarifying that the parameter 'question' is a natural language request, and provides examples, but it does not go beyond what the schema already states.

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 plain English questions by automatically selecting the best data source, filling arguments, and returning results. It specifies the verb 'ask' and the resource 'Pipeworx' and distinguishes itself from sibling tools like discover_tools or jargon_translator_translate by emphasizing natural language queries.

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 this tool: when you want to ask a question in plain English without browsing tools or learning schemas. It gives examples that illustrate use cases, but does not explicitly say 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 already indicate read-only and non-destructive behavior. The description adds behavioral details: market resolution, bet classification, fan-out to packs, and return of an evidence packet with comparison. It does not contradict annotations and provides useful context beyond them.

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 reasonably concise for a complex tool. The primary statement comes first, and subsequent sentences explain the process and usage. Could be slightly tighter, but 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 no output schema, the description explains the return value (evidence packet + comparison) adequately. It also covers market resolution, classification, and fan-out behavior. Lacks response format details, but reasonable for a research tool with clear intent.

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

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

Schema coverage is 100%; both 'market' and 'depth' are fully described in the schema. The description repeats the parameter meanings (slug/URL/text, quick vs thorough) without adding new information, 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 identifies the verb ('Research a Polymarket bet') and resource (Pipeworx data for a bet). It distinguishes the tool by stating it's the 'core demo product' that handles market resolution, classification, and fan-out, contrasting with siblings that may require manual pack discovery.

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...'), implying context for usage. However, it does not explicitly state when not to use or name alternative tools, though the contrast with 'agents that have to discover the packs themselves' serves as implicit comparison.

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 return data (paired data + pipeworx:// URIs) and data sources (SEC EDGAR, FDA). It does not mention rate limits or auth needs, but for a read-only comparison tool, core behavioral traits are sufficiently covered.

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

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

Two sentences, zero waste. The first sentence instantly conveys the core purpose and scope (2-5 entities, side-by-side), and the second provides type-specific details and efficiency benefit. Ideal structure.

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

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

Given no output schema, description adequately explains return data (paired data + URIs). It covers both entity types with specific metrics. Missing details like error handling or pagination, but for a moderate-complexity tool, it is sufficiently complete 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?

Input schema has 100% coverage for both parameters. Description adds meaning beyond schema by listing the specific financial metrics for company type (revenue, net income, cash, long-term debt) and drug metrics (adverse-event count, FDA approval count, active trial count), enriching the agent's understanding.

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

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

Description clearly states it compares 2-5 entities side by side with distinct metrics per type (company vs drug), explicitly naming the data sources (SEC EDGAR, adverse-event reports). This distinguishes it from sibling tools like resolve_entity or ask_pipeworx, which are single-entity or general query 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?

States it replaces 8-15 sequential calls, implying efficiency for multi-entity comparisons. While it does not explicitly list when not to use it, the sibling tools are clearly different (memory, single entity, discovery), so context is clear. Could benefit from explicit 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?

No annotations are provided, so the description carries the burden. It mentions that the tool 'returns the most relevant tools with names and descriptions', which is helpful. However, it does not disclose behavior like whether the search is based on vector similarity or keyword matching, or any limitations. The description is adequate but not detailed.

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 three sentences, each providing essential information: purpose, what it returns, and when to use it. No wasted words, well-structured.

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

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

Given the tool's low complexity (2 parameters, no output schema, no nested objects), the description is complete. It covers purpose, usage, and parameter details sufficiently for an agent 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 100%, so the baseline is 3. The description adds value by explaining the 'query' parameter's usage with examples ('analyze housing market trends', etc.) and clarifies the 'limit' parameter's default and max. This goes beyond the schema's description, warranting a 4.

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

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

The description clearly states the verb 'Search' and the resource 'Pipeworx tool catalog', and specifies the purpose: finding the right tools for a task. It also distinguishes itself from siblings by being the tool to call first when many tools are available.

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 'Call this FIRST when you have 500+ tools available', providing clear when-to-use guidance. It also implies that other tools like ask_pipeworx, forget, etc., are for different purposes, though alternatives are not explicitly listed.

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

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

No annotations provided, but the description covers that it makes a single call replacing 10-15 sequential calls, implying batching. It does not explicitly mention side effects or idempotency, but given it's a retrieval operation, this is adequate.

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

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

The description is concise, four sentences long, with each sentence adding essential information. It front-loads the purpose and efficiently lists data types.

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 and no output schema, the description covers purpose, usage guidelines, parameter details, and alternatives. It is complete and leaves no obvious 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 2 parameters with 100% description coverage. The description adds significant value by explaining the value parameter accepts ticker or CIK (not names) and clarifies that type only supports 'company', going 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 explicitly states it returns a full profile of an entity across multiple packs, listing specific data types (SEC filings, revenue, patents, news, LEI) and citation URIs. It distinguishes from siblings by noting federal contracts should use usa_recipient_profile.

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 clearly indicates when to use (for broad entity profile) and when not to use (federal contracts) with a direct alternative. It also advises using resolve_entity if only a name is available, providing clear 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?

No annotations are provided, so the description bears the full burden. It states 'Delete' implying mutability, but does not disclose side effects, irreversibility, or error conditions. The behavior is minimally described.

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, clear sentence with no wasted words. It is appropriately concise for a simple tool with one parameter.

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 (1 param, no output schema), the description is minimal. It lacks information about return value, error states, or confirmation, which would be helpful for an agent.

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

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

Schema coverage is 100%, so the schema already documents the single parameter. The description adds 'by key' confirming the parameter's role, but does not elaborate on format or constraints beyond the schema.

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

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

The description clearly states the action ('Delete') and the resource ('a stored memory by key'). It distinguishes itself from siblings like 'recall' (read) and 'remember' (write), but could be more explicit about the uniqueness of 'forget' among them.

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

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

No guidance is provided on when to use this tool vs. alternatives. It does not mention prerequisites (e.g., memory must exist) or cases where deletion might fail, leaving the agent to infer usage from 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 declare readOnly, idempotent, non-destructive. Description adds detailed behavior: fetches page, extracts title/description/key links, emits markdown. 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 sentences plus a bulleted list. Main purpose and output format front-loaded. Use cases presented clearly. No unnecessary words.

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

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

Covers purpose, behavior, output format, and use cases. Without output schema, description sufficiently explains return value. Tool complexity is low; description is 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 covers both parameters with descriptions. Description does not add extra parameter details beyond what schema provides. Baseline score applies due to 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?

Clearly states 'Generate a production-ready llms.txt file for any URL', with specific verb and resource. Explains extracted components and output format. Distinguished from siblings by unique 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?

Explicitly lists three use cases: indexing, drafting, auditing. Provides clear context for when to use. No explicit alternatives or when-not, but uniqueness among siblings compensates.

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

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

With no annotations, the description fully discloses the tool's behavior: it performs translation and returns interpretation tips. No side effects or special behaviors are hidden; the tone parameter influences output. This is adequate for a stateless translation 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 exceptionally concise: two sentences that cover purpose, parameters, and output hints. Every word adds value, 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?

Given the tool's low complexity and the presence of a complete input schema and output schema, the description covers all essential aspects. It is sufficient for correct invocation, though an example of the output format could slightly enhance 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%, and the description adds value by noting that the tool returns 'interpretation tips' beyond the raw translation. This extra information helps the agent understand the output richness not fully captured in the input schema or output 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: 'Translate between corporate jargon and plain English.' It specifies the direction and tone options, making it distinct from all sibling tools (e.g., ask_pipeworx, compare_entities) which are unrelated.

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 the tool by specifying the two directions and three tone options. While it doesn't explicitly state when not to use it or name alternatives, the context is clear given no similar sibling tools 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?

Despite no annotations, the description discloses the rate limit ('5 messages per identifier per day. Free.') and advises on appropriate content, providing transparency about behavioral constraints. It does not mention any destructive actions, which is expected 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?

The description is extremely concise (two sentences) and well-structured: it starts with the core purpose, then lists use cases, followed by content guidelines and rate-limit info. No unnecessary words.

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

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

The description fully covers purpose, usage, content guidelines, rate limits, and parameter hints. No output schema is needed for a feedback tool, and the missing information is not required for effective 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?

With 100% schema coverage, the description adds value by guiding on message content ('Describe what you tried...' and 'do not include the end-user's prompt'), complementing the schema's type and context descriptions. This enhances parameter understanding.

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

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

The description clearly states 'Send feedback to the Pipeworx team' and enumerates specific use cases (bug reports, feature requests, missing data, praise), making the purpose unambiguous and distinct from sibling tools which focus on queries or data retrieval.

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

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

The description provides explicit guidance on what to include ('Describe what you tried in terms of Pipeworx tools/data') and what to avoid ('do not include the end-user's prompt verbatim'), along with rate-limit information. It does not explicitly state when not to use the tool, but the use cases 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?

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

Concise paragraph with front-loaded main functionality. Every sentence adds value, including three use cases and technical details about caching and privacy.

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 adequately specifies return structure (top tools, top packs, total call volume) and key constraints (no PII, caching). Complete for a simple 1-parameter 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?

Single parameter 'window' with enum and schema description at 100% coverage. Description adds interpretation ('shorter windows surface what's hot right now; longer windows show steady-state demand'), going 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 'Returns the top tools, top packs, and total call volume' with specific verb+resource. It distinguishes from siblings like 'discover_tools' by specifying it's about AI agent call trends on Pipeworx.

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?

Three explicit use cases are listed (discovering hot data, confirming canonical choice, seeing alignment). While it doesn't explicitly exclude alternatives, the context is clear enough for an agent to decide.

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 readOnly and non-destructive. Description adds detailed behavioral context: how it walks child markets, groups related markets, checks monotonicity, and returns ranked opportunities with reasoning. 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?

Approximately 120 words, well-organized with clear mode breakdown. Every sentence adds value; no redundancy. Front-loaded with the core purpose and immediately provides actionable structure.

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

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

Despite no output schema, the description explains what is returned (ranked opportunities with suggested trade direction + reasoning). Covers both modes fully, preconditions (need for related markets), and the underlying logic. Complete for an agent to understand and use correctly.

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

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

Schema coverage is 100%, but the description adds rich semantics: explains the two modes, gives example values for event slug and topic, and clarifies how each parameter triggers different behavior. This goes well beyond the schema's brief property 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?

Clearly states the tool finds arbitrage opportunities via monotonicity violations. Lists two specific modes (event and topic) and explains their difference, distinguishing it from siblings like polymarket_edges or bet_research.

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 guidance: event mode for a single event, topic mode for cross-event searches. Includes a concrete example (May 31 vs Jun 30) showing why topic mode is needed, effectively directing the agent to the right 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?

Annotations already indicate readOnlyHint, but the description adds substantial behavioral details: the lognormal model from FRED, live coinpaprika price, scanning and grouping logic, ranking by |edge|. No contradictions; 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?

The description is front-loaded with the main action, well-structured, and each sentence adds necessary context. Slightly verbose with technical details but still efficient and comprehensive.

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

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

Despite no output schema, the description explains the return (top N ranked by edge magnitude with suggested trade direction) and covers all inputs, modeling assumptions, and limitations (V1, crypto-only). Completely sufficient for an agent to use the tool.

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

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

Schema description coverage is 100% with clear defaults and enums. The tool description adds minimal extra meaning (e.g., 'V1 covers crypto-price bets'), but the parameters are already well-explained in the schema, so the description adds only marginal 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?

The description clearly states the tool scans high-volume Polymarket markets, computes disagreement ('edge'), and returns ranked results. It specifies the domain (crypto-price bets) and differentiates from siblings like polymarket_arbitrage by focusing on the 'what to bet on' question.

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 the tool is built for discovering betting opportunities without manual paging, giving clear use case. However, it does not explicitly state when not to use it or list direct alternatives, though the sibling list provides context.

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

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

Annotations already declare readOnly, openWorld, idempotent hints. Description adds output format (raw probability 0-1, spread in percentage points) and emphasizes that the spread is a real arbitrage signal, enhancing understanding 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?

Two paragraphs, ~120 words, front-loaded with purpose. Every sentence adds distinct value: concept, modes, output format. No filler or 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 exists, so description properly explains return values. Covers both modes and parameter interactions. Lacks an example or mention of data freshness, but completeness is adequate for a non-nested tool with good annotations.

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 crucial semantics: explains the topic parameter as pre-mapped shortcuts (listing values) and clarifies that explicit ticker/slug overrides the topic-mapped side. This mode logic is not in the schema alone.

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?

Clear verb-resource pair: 'cross-venue spread between Kalshi and Polymarket'. Specific about modes (topic vs explicit) and output (prices, spread). Distinguishes from siblings like polymarket_arbitrage by focusing on the same resolving question across two venues.

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 two modes with clear use cases: topic for pre-mapped shortcuts, explicit for custom pairings. Does not mention when not to use or contrast with sibling tools, but provides sufficient context for 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?

No annotations provided, so description carries full burden. It clearly states retrieval behavior and that omitting key lists all, which is sufficient for a non-destructive read operation.

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

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

Two clear sentences, front-loaded with verb and resource, no wasted words.

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

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

Given single optional parameter, no output schema, and simple read operation, description is complete enough. It covers the key behavior and the list-all fallback.

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 schema already describes 'key' as memory key to retrieve. Description adds nuance that omitting key lists all, but this is already implied by non-required parameter. Baseline 3 is appropriate.

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

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

Clearly states the tool retrieves a memory by key or lists all if key omitted, distinguishing it from 'remember' (store) and 'forget' (delete).

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

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

Explicitly says to use for retrieving context saved earlier, and implies omitting key to list all. No explicit alternatives or when-not-to-use, but sibling names clarify roles.

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

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

With no annotations, the description carries the full burden. It discloses parallel fan-out to multiple sources, accepted date formats (ISO and relative), and return structure (structured changes, count, URIs). It does not explicitly state read-only behavior, but the description implies it. A bit more detail on side effects would improve it.

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

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

The description is three sentences long, with the primary purpose stated first. Every sentence contributes unique information: parallel sources, date formats, return values, and usage suggestion. No repetition or 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 3 parameters, no output schema, and no annotations, the description covers the essential aspects: what the tool does, how to use each parameter, what it returns, and when to use it. It could detail the return format more, but it's sufficient for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing examples of relative date strings ('7d', '30d', '3m', '1y') and clarifying that value can be a ticker or CIK. This goes beyond the schema's 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's purpose: 'What's new about an entity since a given point in time.' It specifies the entity type (company) and the sources it fans out to (SEC EDGAR, GDELT, USPTO), distinguishing 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?

The description explicitly says, 'Use for "brief me on what happened with X" or change-monitoring workflows,' providing clear usage context. It does not explicitly exclude other uses or name alternatives, but the purpose is distinct 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?

The description discloses persistence behavior: authenticated users get persistent memory, anonymous sessions last 24 hours. No annotations are provided, so the description compensates well for this gap.

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

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

The description is three sentences, each adding value: first sentence defines the action, second gives use cases, third discloses persistence. 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 tool is simple with only two required string params and no output schema. The description covers purpose, usage, and behavioral notes. It could mention that memory is per-session and that keys must be unique, but it's largely complete.

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

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

Schema coverage is 100% with good descriptions for both parameters. The description adds little beyond the schema; it implies what values might be stored (findings, addresses) but doesn't add constraints or formatting 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?

The description clearly states the tool stores a key-value pair in session memory, distinguishing it from sibling tools like 'recall' (retrieve) and 'forget' (delete). The verb 'store' and resource 'key-value pair' are specific.

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 usage contexts: save intermediate findings, user preferences, or context across tool calls. It doesn't explicitly state when not to use it or name alternatives, but the sibling context provides some differentiation.

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

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

No annotations provided, but the description discloses it is a single-call lookup, returns specific fields, and implies no side effects. It does not mention authentication or rate limits, but for a read-like operation, this is sufficient.

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

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

Two sentences with a bullet-like list; no wasted words. Purpose is front-loaded, and all information is relevant and compact.

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

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

Given no output schema, the description adequately explains the return values (ticker, CIK, company name, URIs) and covers all aspects of the tool's use: type, input formats, and purpose.

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

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

Schema coverage is 100% with descriptions. Description adds value by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and explaining the output structure, going 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 resolves entities to canonical IDs, specifies supported type (company), input formats (ticker, CIK, name), and outputs (ticker, CIK, company name, URIs). It distinguishes from alternatives by noting it replaces 2-3 lookup 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?

The description indicates when to use the tool (to resolve entities in a single call) and what it replaces, but does not explicitly state when not to use it or compare to sibling tools. However, given no direct competitor, it is adequate.

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 declare readOnly, openWorld, idempotent, non-destructive behavior. The description adds value by detailing the internal process (calling ai_visibility_check per entity), output format (ranked list with score, confidence, signal density), and narrative treatment of the first entity. 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 about four sentences with no wasted words. It front-loads the core purpose, then explains process, use case, and output. 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?

No output schema, but the description covers return structure. Given the tool's complexity (multiple entities, optional models/API key/context), the description adequately covers usage without gaps. Slight deduction for missing error handling or rate limit notes, but annotations mitigate.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: e.g., 'First entry treated as the subject for narrative', 'Omit for just workers-ai' for models, and context disambiguation example. This extra context justifies a score above baseline 3.

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

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

The description explicitly states the tool compares AI visibility across multiple entities side-by-side, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It clearly differentiates from its sibling ai_visibility_check by describing aggregation and comparison, and provides a concrete use case example.

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 a clear use case (competitive AI-marketing audits) and an illustrative question. It does not explicitly state when not to use or list alternatives, but the context is sufficient for an agent to understand appropriate usage. Slight deduction for missing 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?

No annotations provided, so description carries full burden. It explains return values (verdict, extracted form, actual value with citation, percent delta) and indicates it is a read-only operation. Lacks details on authentication, rate limits, or edge cases, but is sufficiently transparent for a fact-checking 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?

Three sentences: first defines purpose, second specifies scope and output, third highlights efficiency. No fluff, front-loaded, every sentence is informative.

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

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

With a single parameter and no output schema, the description covers the key output fields (verdict, extracted form, actual value, citation, delta) and explains the replacement benefit. It is complete for a well-scoped 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 has 100% coverage with a description for the single 'claim' parameter. The tool description adds value by giving examples and specifying domain constraints, which goes beyond the schema's generic 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?

Clearly states 'fact-check a natural-language claim against authoritative sources' and specifies domain (company-financial claims for US public companies) and data sources (SEC EDGAR + XBRL). Distinguishes from siblings by noting it replaces multiple 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 explicit domain restrictions (v1 supports company-financial claims for US public companies) and lists supported metrics (revenue, net income, cash). Does not explicitly mention when not to use or name alternatives, but the domain guidance is clear enough for an agent to decide.

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