Hnb Hr

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

Annotations already declare readOnlyHint and idempotentHint. The description adds context: it is a probe that returns scores per model, requires an external API key for Anthropic, and involves direct payment. No contradiction, and it clearly conveys non-destructive, read-only behavior.

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

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

Two well-structured sentences, front-loaded with the core action, no filler. Every sentence provides essential information.

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

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

Given the 4 parameters and no output schema, the description fully explains the input options and return structure. It also fits within the sibling tool set, providing enough context for an agent to use it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default model behavior, the role of _apiKey, and how context helps disambiguate. 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 uses 'Probe one or more LLMs for what they know' — a specific verb and resource. It clearly distinguishes from siblings by focusing on visibility scoring per model. The output structure is also explicitly stated, leaving no ambiguity.

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 mentions use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains when to use the optional API key. However, it does not explicitly state when not to use or mention alternatives like the sibling tool 'scan_competitor_ai_presence'.

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 safety (readOnlyHint, idempotentHint, etc.). The description adds valuable context: it routes to the correct tool from 3,272 sources, fills arguments, and returns structured answers with citation URIs. 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 front-loaded with the most important guidance (prefer over web search), then systematically covers domains, mechanism, usage cues, and examples. Every sentence is informative and there is no redundancy. Length is justified by the tool's complexity.

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

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

Given the tool's complexity (many sources, no output schema), the description provides sufficient context: it explains the routing mechanism and that answers include citations. It could be more specific about the return format, but the examples and domain coverage make it adequate for an agent to understand its capabilities.

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 does not add any new information beyond what the schema already provides for the parameters (question with aliases). No additional semantics or examples of parameter values are given.

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: to answer factual questions about real-world entities using structured data from 3,272 tools. It uses strong verbs like 'ask' and explicitly distinguishes from web search. The extensive list of example domains and queries leaves no ambiguity.

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

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

Explicitly instructs to prefer over web search for specific types of questions (SEC filings, FDA data, etc.) and provides non-exhaustive examples. Also gives usage cues like 'what is', 'look up', 'find' etc., making it clear when to select this tool over 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 already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description goes far beyond, detailing fan-out by category, resolver contract (match confidence, alternatives), parent event extraction, news fallback handling, and safety mechanisms (short-circuit on low confidence, closed markets). 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 verbose but well-structured, with clear sections (classifiers, fan-out examples, response shapes, resolver contract, safety). The first sentence front-loads the main purpose. However, some details (e.g., specific fan-out examples) could be condensed or moved to a separate guidance document without losing essential clarity.

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

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

Given the tool's complexity (multiple classifiers, fan-out, resolver, edge cases), the description covers all major aspects: input formats, response shape (market, analysis, evidence), status codes, blocking conditions, and special fields. Without an output schema, the description adequately explains what the agent can expect from the response.

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 context: explains how 'market' accepts slug/URL/text, 'depth' distinguishes quick vs thorough with defaults, and 'include_raw' specifies when to use (e.g., recomputing deltas). This adds significant meaning beyond 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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies input types (slug, URL, question text) and provides examples. The purpose is distinct from sibling tools like polymarket_edges and polymarket_arbitrage, which target different tasks.

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 use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also describes cases where the tool returns blocking statuses (low-confidence match, market closed). However, it does not explicitly list alternatives or when not to use, leaving some ambiguity relative to nearby sibling tools.

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

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

Beyond the annotations (read-only, idempotent), the description details data sources (SEC EDGAR/XBRL for companies, FAERS/FDA for drugs), special handling of fiscal years, sorted results, and citation URIs. This provides comprehensive behavioral insight without contradiction.

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

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

The description is front-loaded with the main purpose and is well-structured. While it is somewhat long, each sentence earns its place, and the information is presented in a logical order without redundancy.

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

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

Given the tool's complexity (two entity types, multiple data sources, sorting, URIs), the description covers key aspects. It explains the return format (paired data + citation URIs) and sorting behavior, though a brief example of output structure would improve 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%, but the description adds meaningful context: examples of tickers/drug names for 'values', and clarifies what financial metrics are pulled for 'type=company' versus adverse events for 'type=drug'. This goes beyond the schema's enum and item 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 compares 2-5 entities side by side, with specific use cases like 'compare X and Y' and 'which is bigger'. It distinguishes between company and drug types, and mentions it replaces sequential lookups, making the purpose very specific and 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 advises when to use the tool (for comparison questions) and provides examples. However, it does not mention when not to use it or suggest alternative tools among siblings, though the context makes the usage scope 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 indicate read-only, open-world, idempotent, and non-destructive. The description adds crucial behavioral details: comma decimal separator, reference rate field name, date format, and parameter interactions. 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 concise (5 sentences) and well-structured: purpose, usage modes, format details. Every sentence adds value with no redundancy.

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

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

Given no output schema, the description explains output format (srednji_tecaj, comma decimal, date format). It covers all parameters, their interactions, and provides examples. Annotations fill safety/behavioral gaps.

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

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

Schema coverage is 100%, baseline is 3. The description adds value by explaining how parameters interact (e.g., date ignored if start_date given) and provides examples of valid currency codes. This goes beyond 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 it provides HNB exchange rates for one foreign currency against EUR, with specific verb 'HNB exchange rate' and resource 'ONE foreign currency vs EUR'. This differentiates it from sibling tools like 'exchange_rates' by specifying single currency and base currency.

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 defines three usage modes (latest, single historical date, time series) and instructs to pass a 3-letter ISO code. It lacks explicit mention of when not to use this tool versus alternatives, but the modes are 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 show read-only and idempotent. Description adds that it returns top-N relevant tools with full input schemas and curated examples, and that no second schema lookup is needed. 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, no wasted words. Purpose, usage, and return format are front-loaded. Every sentence earns its place.

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

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

Despite no output schema, the description explains what each result contains (name, description, full input schema). For a discovery tool with 6 parameters and 1 required, it is complete and self-contained.

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%. Description adds meaning by listing aliases for the query parameter and providing examples for query and limit (default 20, max 50). This adds value 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 'Find tools' and lists specific domains (SEC filings, FDA drugs, etc.), distinguishing it from sibling tools which are more specific. It explains that it returns top-N relevant tools with full schemas ready to call.

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 'Call this FIRST when you have many tools available and want to see the option set', providing clear usage context. No explicit when-not-to-use, but the purpose is well-defined.

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 (readOnlyHint, idempotentHint, etc.), the description discloses important behaviors: the patents field soft-fails due to sunset, news uses a GDELT→GNews fallback, fundamentals are sorted by period_end descending and reflect latest 10-K, and filings return up to 5 with pipeworx URIs. 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 front-loaded with the primary purpose and use cases, then efficiently lists return components with necessary caveats in a structured bullet-style format. Every sentence provides value, and the information is well-organized despite the tool's complexity.

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

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

Given the tool's multi-source nature and no output schema, the description comprehensively covers what the tool returns (recent filings, fundamentals, patents, news, LEI) with state details and limitations. It also explains the input format constraints and prerequisite, making it fully contextual for an AI agent to invoke 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?

While the input schema already describes parameters (type enum and value string), the description adds crucial context: only 'company' is supported for type (people/places coming soon), value accepts ticker or zero-padded CIK, and it explicitly states names are not supported, directing to resolve_entity as a prerequisite. This significantly aids correct invocation.

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

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

The description clearly states the tool's purpose: 'Get everything about a US public company in one call.' It specifies the resource (US public company) and action (get everything), and distinguishes it from siblings like compare_entities and resolve_entity by offering a comprehensive alternative to calling multiple individual tools.

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

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

The description explicitly defines when to use the tool: when a user asks for company research ('tell me about X', 'research Acme', etc.) or when you'd otherwise call 10+ pack tools. It also provides a clear exclusion: if you only have a name, use resolve_entity first, as names are not supported.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context beyond annotations: it explains the base currency (EUR), the return structure (valuta, three tecaj fields, datum_primjene), and a critical detail that rate values are strings with comma decimal separator. This fully informs the agent of the tool's behavior.

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

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

The description is extremely concise: two well-structured sentences. The first sentence states the tool's main purpose and key context (base currency, national bank). The second sentence lists output fields and important formatting details. Every sentence is informative and earns its place; no unnecessary information.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is fully complete. It covers the purpose, parameter usage, output structure, and a critical data formatting detail (comma decimal separator). There are no gaps in information that an agent would need to correctly 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 a clear description of the 'date' parameter (format, example, omission behavior). The tool description adds context about the currency base and output format, but does not provide substantial new meaning about the parameter itself beyond what the schema already says. 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 very clearly states it provides HNB official exchange rates for all foreign currencies against the Euro on a given date. It uses specific verb 'exchange rates' and resource 'HNB official exchange rates', and distinguishes itself by specifying the base currency and national bank context. Its purpose is unambiguous and well-defined.

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

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

The description provides clear context on when to use this tool: when official Croatian exchange rates for any foreign currency are needed, optionally on a specific date or the latest. It explicitly states 'Omit date for the latest applicable rates.' However, it does not explicitly compare with siblings like 'currency_rate' to guide when not to use this tool.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds context on appropriate usage conditions (e.g., clearing sensitive data), extending beyond the 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 efficient sentences: first states the action, second provides usage context and associations. No wasted words.

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

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

For a simple tool with one required parameter and no output schema, the description covers purpose, usage context, and sibling relationships comprehensively.

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

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

Schema coverage is 100% with a clear description for the 'key' parameter. The description does not add significant meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the action 'Delete' and the resource 'previously stored memory by key'. It distinguishes from siblings by referencing 'remember' and 'recall' as paired 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?

Provides explicit when-to-use scenarios (stale context, task done, clear sensitive data) and mentions pairing with remember/recall as alternatives. Lacks explicit when-not-to-use but is still 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds valuable behavioral details: fetches page, extracts title/description/key links, emits standard 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?

Description is three well-structured sentences, front-loaded with the core action. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (2 params, no output schema) and rich annotations, the description fully covers the process, output format, and use cases. No gaps identified.

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

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

Schema coverage is 100% with clear descriptions for both parameters (url, max_links). The description does not add extra meaning or format constraints beyond what the schema provides, so baseline score applies.

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

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

Description clearly states the tool generates a production-ready llms.txt file for any URL, with specific verb+resource. It distinguishes from siblings like ai_visibility_check and scan_competitor_ai_presence by focusing on file generation.

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 lists explicit use cases (getting site indexed, drafting own project, auditing competitors), providing clear context. However, it does not explicitly mention when not to use this tool or name 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?

Beyond annotations, the description discloses rate limiting (5 per identifier per day), free usage, and that feedback doesn't count against tool-call quota. Also explains team processes (daily digests, roadmap impact).

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 and well-structured: opens with purpose, then usage guidelines, then behavioral details. Every sentence adds value without redundancy.

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

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

As a simple feedback tool with no output schema, the description covers all needed context: what the team does with feedback, rate limits, and how to format the message. No gaps.

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

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

Schema coverage is 100%, but description adds helpful formatting guidance (be specific, 1-2 sentences, 2000 chars max, describe in terms of tools/packs) that the schema lacks.

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

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

The description clearly states the tool is for sending feedback (bugs, features, praise) to the Pipeworx team, distinguishing it from sibling tools like ask_pipeworx or discover_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?

Provides explicit when-to-use scenarios (bug, feature, data_gap, praise) and what not to do (don't paste end-user prompt). Includes rate limits and quota info.

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

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

Annotations already cover read-only, idempotent, non-destructive nature. The description adds value by explaining data source (CF analytics-engine), lack of PII, and caching behavior (5min-1h), which are not in 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 concise (~80 words), uses bullet points for use cases, and front-loads the main output. Every sentence adds value, with no redundancy.

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

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

Without an output schema, the description lacks detail on the exact structure of the return value (e.g., how top tools/packs are formatted). However, the use cases and technical context are adequately covered.

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 meaning by explaining that shorter windows surface hot trends and longer windows show steady-state demand, beyond the enum description.

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

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

The description clearly states the tool returns top tools, packs, and call volume over recent windows. It uses specific verbs and resources, distinguishing it from siblings like 'discover_tools' or 'ask_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?

The description lists three explicit use cases (discovering hot data, confirming canonical choice, seeing alignment with agent needs). While it does not state when not to use or mention alternatives, the use cases are clear and practical.

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 readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details: it performs monotonicity checks, partition-sum checks, and filtering. It does not contradict the 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 well-structured with bolded terms and clear sections for modes, filters, and response. It is somewhat long but every sentence provides valuable information. Could be slightly more 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?

Given the complexity of the tool (two modes, partition checks, semantic anchor, filtering), the description is remarkably complete. It covers the algorithm, input formats, response structure, and edge cases, compensating for the lack of an output schema.

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

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

Schema description coverage is 100% for both parameters. The description adds significant meaning by explaining the modes, example inputs, and how each parameter is used (e.g., event slug vs topic seed question).

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 finds arbitrage opportunities via monotonicity violations and partition-sum checks, with two distinct modes (event and topic). It clearly distinguishes from siblings like polymarket_edges or polymarket_kalshi_spread, which have different purposes.

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 explains when to use event mode (single slug) vs topic mode (seed question), and that cross-event mode catches patterns missed by single-event. It also describes filters (Jaccard similarity, partition placeholder filter). However, it does not explicitly state when NOT to use the tool or list alternatives.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior, but the description adds extensive detail: three model families with specific formulas, caching at 1-hour KV level, diagnostics for empty segments, and edge calculation including slippage and 24h-move warnings. 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 lengthy but well-organized with clear sectioning via parentheses and bold terms. It is front-loaded with the core purpose and each sentence adds necessary detail. Could be slightly more structured but earns its 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 covers return fields (edge_pp_net, kelly_fraction, market.liquidity, etc.), explains caching, diagnostics, and Fed note. It is fully self-contained for a complex tool with 9 parameters and no nested objects.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the intent behind min_liquidity, max_spread_pp, and min_partition_leg_kelly, and how they relate to tradeability. However, most parameter details are already 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 the tool scans Polymarket for opportunities where Pipeworx data disagrees with market price, specifically for daily betting decisions. It distinguishes itself from sibling tools like polymarket_arbitrage and bet_research by focusing on edge detection without manual paging.

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 targets agents seeking daily betting opportunities, explains when to use tradeable-edge knobs (min_liquidity, max_spread_pp), and provides context on when segments might be empty via diagnostics. It also flags Fed bets as excluded from ranking, guiding appropriate use.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it explains safety fields (compatibility_warning, temporal_alignment), skipped counters, and the logic behind matched_pairs. It also indicates that the tool may return warnings rather than invalid data, providing transparency 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 well-structured with sections for purpose, modes, response, and safety fields. It is front-loaded with the main purpose. However, it is somewhat verbose with detailed explanations of skipped types; could be slightly more concise without losing clarity.

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

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

Despite having no output schema, the description thoroughly explains the response structure: leg-by-leg prices, spread array, compatibility_warning, temporal_alignment, and skipped counters. It covers edge cases and safety fields, making the tool's behavior fully predictable.

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 all parameters described. The description adds value by explaining the topic list (10 shortcuts) and how explicit parameters override the mapped side. It also explains that 'topic' auto-fetches events on each venue, adding meaning beyond the schema's simple enum listing.

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

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

The description clearly states it is a 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It specifies the action (comparing prices and calculating spreads), the resource (two prediction market venues), and distinguishes it from sibling tools like 'polymarket_arbitrage' by focusing on cross-venue spreads for the same event.

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 two usage modes (topic shortcuts and explicit tickers) and provides context on when spreads are meaningful vs when they are not (e.g., compatibility_warning, temporal alignment). It warns that most pre-mapped topics are not tradeable. However, it does not explicitly state when to use an alternative tool, but the 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description correctly aligns. It adds behavioral context about scoping (anonymous IP, BYO key hash, account ID) and the non-re-derivation benefit. 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, first states core purpose, second adds usage context and pairing. No superfluous words; efficient 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 single optional parameter, annotations present, and no output schema, the description fully covers behavior (with/without key), scope, and integration with sibling tools (remember/forget). It leaves no gaps.

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

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

Schema coverage is 100% with description for key: 'Memory key to retrieve (omit to list all keys)'. Tool description adds that omitting key lists all keys and mentions scoping, providing 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 it retrieves a saved value or lists all keys, with specific verb 'Retrieve' and resource 'value previously saved via remember'. It distinguishes from sibling tools 'remember' and 'forget' by name and 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?

Explicit guidance on when to omit the key argument (to list all keys) and context for using it to look up stored information without re-deriving. Mentions scoping and pairing with remember/forget, but does not explicitly state when NOT to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing the tool as safe and idempotent. The description adds substantial behavioral context beyond annotations: it explains the parallel fan-out to multiple sources (SEC EDGAR, GDELT→GNews fallback, USPTO with soft-fail note), which is critical for understanding the tool's behavior and potential latency or failure modes.

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 about 6 sentences. It front-loads the main purpose and use cases, then provides technical details. While comprehensive, it could be slightly more structured with bullet points for the parallel sources, but it remains clear and efficient without excess verbosity.

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

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

The tool has no output schema, so the description must explain return values. It does: 'Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs.' It also covers edge cases (GDELT fallback, USPTO soft-fail) and provides usage examples. Given the complexity (3 parameters, no output schema, multi-source fan-out), the description is remarkably 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?

Input schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema, particularly for the 'since' parameter: it explains both ISO date and relative shorthand formats with examples ('7d', '30d', '3m', '1y') and recommends typical values ('Use "30d" or "1m" for typical monitoring'). This guidance enhances parameter understanding beyond the schema's basic type 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 with a company in the last N days/months?' and lists specific use cases like 'what's happening with X' and 'updates on Y'. It also distinguishes itself from sibling tool 'entity_profile' by explicitly stating when to use the alternative.

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: 'Use for ...' and 'Use entity_profile instead when you want the static profile ...'. This clearly delineates usage scenarios and alternatives, helping the agent make the correct selection.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. Description adds scoping by identifier and persistence differences (authenticated vs anonymous). Could mention overwrite behavior explicitly, but overall good.

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

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

Very concise and front-loaded. First sentence states purpose, then usage, then details. 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?

Good context for a simple key-value store. No output schema, but not critical. Could mention return value or error cases, but acceptable.

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

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

Schema has 100% description coverage for both key and value. Description adds no additional meaning beyond examples, so baseline score of 3.

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

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

The description clearly states the tool saves data for later reuse, with specific examples like 'resolved ticker, target address, user preference'. It distinguishes from siblings 'recall' and 'forget'.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward'. Also pairs with recall and forget, providing complete usage guidance.

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

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

Annotations already indicate idempotent, read-only behavior. The description adds valuable behavioral context: internal cascading through multiple endpoints, auto-disambiguation for companies, and replacement of manual lookups. 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 well-structured and front-loaded with the primary purpose. While it is fairly detailed, every sentence adds value, and there is no redundancy. Could be slightly tightened but overall effective.

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

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

Given the simplicity of the input schema and the presence of annotations covering safety, the description is quite complete. It explains what the tool returns for each type and the internal process, though it omits error handling or 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?

The input schema has 100% description coverage. The description enriches it with examples, auto-disambiguation details, and specific return identifiers for each type, going beyond the schema's simple 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 resolves user-spoken names to canonical identifiers, with specific examples for company and drug types. It distinguishes itself from sibling tools that compare or profile 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 FIRST when you have a name but need an ID,' providing clear when-to-use guidance. It does not explicitly list when not to use or alternatives, but the context of sibling tools makes this less critical.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safety. The description adds behavioral details: probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, and signal density. This enriches 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 sentences (about 70 words) efficiently convey purpose, process, use case, and output. No redundancy or fluff. The structure is front-loaded with the core action and then application context.

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 describes the return (ranked list with score, confidence, signal density). It covers the main behavioral aspects (inner workings, entity count, subject treatment). Minor omissions like error handling or rate limits do not detract from overall completeness for typical audit 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 description coverage is 100%, so baseline is 3. The description adds minor context: entities should be 2-8, first is subject; context disambiguates common names. But it doesn't significantly add meaning beyond what the schema already provides (e.g., models and _apiKey are already well-described).

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, using the verb 'compare' and specific resource 'AI visibility across multiple entities'. It distinguishes itself from siblings like ai_visibility_check (single entity) and compare_entities (generic comparison) by focusing on AI presence and ranking.

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

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

The description explicitly provides a use case: 'Useful for competitive AI-marketing audits: "does Claude know about us as well as our competitors?"'. It also implies when to use (multi-entity comparison) and contrasts with the sibling tool ai_visibility_check (single-entity probe). This gives clear guidance on tool selection.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint false. The description adds behavioral details: fans out across two services, partial failures degrade gracefully, first measurement on a new version can take 5-30s, and sources_failed will list timed out sources. No contradiction.

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

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

The description is a single dense sentence, but it packs all necessary information efficiently. It front-loads the composite nature and then details return fields and limitations. Slight improvement could be breaking into shorter sentences, but it remains clear and 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?

Given no output schema, the description comprehensively explains return values (summary block fields, per-advisory detail, links, alternative versions). It covers ecosystem limitation, failure behavior, and timeout caveat. This meets the needs of a complex composite 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 descriptions for both parameters. The description adds minimal extra semantic value (e.g., scoped packages accepted already in schema, version defaults to latest already in 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 it is a composite check for npm packages, fanning out across deps.dev and bundlephobia, and returns a summary block with specific fields. It distinguishes itself from sibling tools by focusing on npm dependencies, unlike other tools like 'scan_competitor_ai_presence' or '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?

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me". It notes NPM ecosystem only in v1 and directs other ecosystems to deps.dev:version. Also describes graceful degradation and timeouts, providing clear when-to-use guidance.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds significant behavioral details: the returned verdict types (confirmed, refuted, etc.), citation format (pipeworx://), and the domain limitation (v1 supports only US company-financial claims). 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 concise: two sentences defining the tool's purpose and usage context, followed by key details about capabilities and output. Every sentence adds necessary information without redundancy.

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

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

Despite the absence of an output schema, the description adequately explains the return values (verdict, extracted form, actual value with citation, percent delta). It also specifies the supported claim types and coverage limitations, making it sufficiently complete for agent understanding.

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

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

Schema coverage is 100% with a clear description of the 'claim' parameter. The description adds value by providing examples and emphasizing that it's a natural-language statement, which enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose as fact-checking/verifying natural-language claims against authoritative sources. It specifies the scope (company-financial claims for US public companies) and distinguishes itself from siblings by its 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?

The description explicitly states when to use the tool (e.g., when checking user claims) and highlights that it replaces multiple sequential calls. However, it does not mention when not to use it or provide explicit alternatives for non-financial claims.

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