Landregistry Uk

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

Annotations already declare read-only, open-world, idempotent, non-destructive. The description adds valuable behavioral details: default free model, BYO Anthropic API key, and return structure (score, confidence, signals, raw_response). No contradictions.

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

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

Three sentences, no wasted words. The first sentence states core action, second details model options, third lists use cases. Perfectly front-loaded and efficient.

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

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

Given 4 parameters, no output schema, but strong annotations, the description covers purpose, defaults, optional models, key requirement, return fields, and use cases. It is thorough but could mention potential cost implications or rate limits for Anthropic probes.

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. The description adds context beyond schema: explains default model for 'models', clarifies that '_apiKey' is only for Anthropic and BYO key, and describes 'context' as disambiguation aid. Adds meaningful 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 defines the tool as probing LLMs to score visibility of a brand/product/topic, with specific verb 'probe' and resource 'visibility score'. It distinguishes from siblings like 'ask_pipeworx' or 'compare_entities' by focusing on AI visibility audits.

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

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

The description states use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring'), but does not explicitly mention when not to use or provide alternatives. It is clear about context but lacks exclusion criteria.

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

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

Annotations already confirm read-only and idempotent behavior. The description adds value by explaining the internal routing mechanism, that it fills arguments automatically, and returns pipeworx:// citation URIs. No contradictions, but could mention potential 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 informative but somewhat lengthy. It is front-loaded with the key 'PREFER OVER WEB SEARCH' directive, followed by scope and examples. Each sentence contributes, but 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 no output schema, the description explains the output format (structured answer with citation URIs) and provides usage examples. It covers the tool's broad applicability. It could mention error handling but is largely complete for its complexity.

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

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

Schema coverage is 100% with descriptions for all parameters. The description does not add new parameter-level details beyond the schema, but it contextualizes the 'question' parameter as natural language input. Baseline 3 is appropriate as no extra semantics are provided.

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

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

The description clearly states the tool routes natural language questions to 3,272 sources and returns structured answers with citations. It distinguishes itself from web search by specifying domains like SEC filings, FDA data, etc. The purpose is specific and action-oriented.

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 tells the AI to prefer this tool over web search for factual queries, provides examples of query types ('what is', 'look up', etc.) and concrete examples like 'current US unemployment rate'. It covers when to use and implies when not to (non-factual or non-structured queries).

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 numerous behavioral traits beyond annotations: it resolves markets, classifies bets, fans out to data packs, returns evidence packets, and handles edge cases like low-confidence matches (short-circuiting), closed markets (status 'market_closed_or_inactive'), and wide spreads (tradeability note). It also explains the resolver contract and market_match_confidence. Annotations already indicate readOnly & idempotent, and the description adds rich context 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 quite long and details many examples and edge cases. It is front-loaded with the main purpose but becomes verbose with classifiers, fan-out examples, and response shapes. While well-structured with sections, it could be more concise by moving some examples to separate documentation. It earns a 3 because it is still organized and readable.

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

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

Given the tool's complexity and the absence of an output schema, the description thoroughly explains every aspect of the response: market fields, analysis fields, evidence keys, resolver contract, parent event extractor, news fields, safety behaviors, and tradeability warnings. It covers edge cases (low confidence, closed markets, wide spreads) and blocking behaviors, ensuring an agent can fully understand the return structure and potential pitfalls.

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 baseline is 3. The description reinforces the usage of the 'market' parameter (slug, URL, or question text) and provides examples in the schema, but does not add substantial new meaning beyond what the schema's description already offers. The 'depth' and 'include_raw' parameters are adequately described in the schema, and the description does not elaborate further.

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

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

The description opens with a clear verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It explicitly lists use cases ('should I bet on X', 'what does the data say about Y') and distinguishes itself from sibling tools like polymarket_arbitrage by focusing on comprehensive research in one 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?

The description provides explicit use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' While it does not explicitly state when not to use this tool or mention alternatives, the use cases are clear and help an agent decide when to invoke this tool over others.

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

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

Annotations already declare readOnlyHint, idempotentHint, and no destruction. The description adds crucial behavioral context: the post-Run-6 fix for accurate FY data, handling of off-calendar fiscal years, specific data sources (SEC EDGAR/XBRL, FAERS, FDA), and the return format (paired data + citation URIs). This fully satisfies the transparency need beyond annotations.

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

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

The description is longer but well-structured: it opens with the core purpose and usage, then details each entity type's data, and closes with efficiency and sorting. Each sentence serves a purpose, though it could be slightly more terse 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?

Given no output schema, the description fully informs the agent about what to expect: paired data by entity, citation URIs, and sorting by primary metric. For a tool with 2 simple parameters and clear return behavior, this is complete enough for effective invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the 'type' enum meanings and giving concrete examples for 'values' (tickers/CIKs for company, drug names). It also notes the min/max items constraint explicitly. This added context justifies a higher score.

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

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

The description uses specific verbs ('Compare', 'pulls', 'returns') and clearly identifies the resources (companies via SEC EDGAR/XBRL, drugs via FAERS/FDA). It distinguishes from sibling tools like 'entity_profile' by being a side-by-side comparison capable of handling 2-5 entities in one 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?

It explicitly lists query patterns ('compare X and Y', 'X vs Y', 'which is bigger', 'rank-by-metric') and states it replaces 8-15 sequential lookups. However, it does not explicitly mention when not to use it or alternative tools for specific niches.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that results include full schemas and examples, no second lookup needed, which provides additional behavioral context beyond annotations.

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

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

Description is mostly concise with front-loaded purpose. The listing of domains is slightly verbose but necessary for clarity. Overall 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 no output schema, description explains return format adequately. It covers the tool's role as a discovery meta-tool. Could mention limitations like rate limits, but not essential for this type.

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 for all parameters. The description does not add significant extra meaning beyond what the schema provides, so baseline of 3 is appropriate.

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

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

The description clearly states the tool finds tools by describing data or task, listing many domains. It distinguishes from siblings as the meta-discovery tool, with specific verb 'find' and resource 'tools'.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set', providing when-to-use guidance and implying when not to use (if tool already known).

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=true, idempotentHint=true), the description discloses important behavioral details: patent API sunset, fundamentals note about real FY2025 numbers, news fallback, and soft-fail behavior. 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 with a clear lead sentence, usage context, and detailed return fields. It is slightly verbose but every sentence provides value. Could be marginally shorter but still 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?

For a complex tool combining multiple data sources, the description is exceptionally complete. It covers return fields, limitations (patent sunset), formatting notes, fallback mechanisms, and prerequisites (use resolve_entity for names). No output schema needed.

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

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

Schema coverage is 100% but description adds critical meaning: type is currently limited to 'company', value format guidance (ticker or zero-padded CIK), and explicitly states names not supported, directing to resolve_entity. This goes 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: 'Get everything about a US public company in one call.' It identifies the specific resource (US public company) and action, and distinguishes it from sibling tools by noting it replaces calling 10+ separate tools.

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

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

Explicitly states when to use (user asks about a company) and when not to use (names not supported, use resolve_entity first). Provides clear guidance on when it's appropriate versus alternatives like resolve_entity.

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

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

Annotations already include destructiveHint=true, so the description's 'Delete' aligns but adds no new behavioral detail. The description does not contradict annotations but adds minimal extra context beyond what is already provided.

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 efficiently convey purpose and usage guidelines. No unnecessary words; front-loaded with the action and resource.

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

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

Given the simple delete operation with no output schema, the description covers the purpose, when to use, and relevant sibling tools. It is sufficient for an agent to correctly invoke 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 coverage is 100% with clear description 'Memory key to delete'. The description does not add further parameter semantics 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 verb 'Delete' and the resource 'a previously stored memory by key', which is specific and distinguishes from sibling tools like 'remember' and 'recall' by explicitly mentioning pairing.

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 guidance on when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with 'remember' and 'recall', indicating 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?

Discloses fetching, extraction, and standard format output beyond annotations. Annotations already indicate read-only, idempotent behavior, so description adds context on input processing and output shape.

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

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

Four sentences, front-loaded with purpose, efficient use of bullet-like listing for use cases. No unnecessary repetition.

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 two parameters, no output schema, and rich annotations, the description covers purpose, input, output format, and use cases completely.

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 description mostly restates schema descriptions for 'url' and 'max_links'. No new parameter-level semantics added.

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 'generate' and resource 'llms.txt file' with specific action: fetches URL, extracts metadata, outputs standard markdown. Distinguishes itself from siblings like 'scan_competitor_ai_presence' by providing a concrete file output.

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

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

Lists explicit use cases: indexing client sites, drafting own projects, auditing competitors. However, does not mention when not to use or compare to alternative tools.

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

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

Annotations already provide safety profile (readOnly, idempotent, non-destructive). Description adds value by stating newest sales first, output fields, and postcode format requirement, enhancing transparency beyond annotations.

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

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

Two sentences, no wasted words, front-loaded with purpose and key details. Efficient and clear.

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?

Complete for a simple read tool: covers inputs, outputs, ordering, constraints, and data source. With full annotations, 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?

Adds significant value beyond schema: clarifies uppercase-space format for postcode, default limit, and valid range (1-500), which schema only describes generically.

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 lists recent property sales for a UK postcode, specifying data source (HM Land Registry), geographic scope (England & Wales), and output fields (price, date, address, etc.), distinguishing it from sibling tools by its specific 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?

Implies usage as a convenience tool for quick postcode lookup; no explicit alternatives or when-not-to-use, but the context is clear given the unique function 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?

Discloses behavioral traits beyond annotations: rate-limited to 5 per identifier per day, free, no quota impact. Also states that the team reads digests daily and signal affects roadmap. Does not contradict annotations.

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

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

Every sentence is informative and earns its place. Front-loaded with core purpose and usage conditions. Well-structured, no fluff.

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

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

Given the tool's simplicity (3 params, no output schema), the description is highly complete. It covers all aspects: what it does, when to use, parameter details, constraints, and team impact.

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 enum values for 'type' (e.g., 'bug = something broke') and provides extra context for 'message' (be specific, 1-2 sentences typical, 2000 chars max). Goes beyond baseline.

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

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

The description clearly states the tool is for providing feedback to the Pipeworx team about broken, missing, or needed things. It specifies four types (bug, feature, data_gap, praise) and distinguishes from sibling tools like ask_pipeworx by focusing on feedback rather than questions.

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

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

Explicitly states when to use: for wrong/stale data (bug), missing tools (feature/data_gap), or praise. Provides guidance to describe issues in terms of Pipeworx tools/packs and not to paste user prompts. Also mentions rate limits and that it's free and doesn't count against quota.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes beyond by revealing that the data is self-aggregating from an analytics engine, no PII, cached for 5min-1h. This provides critical behavioral context 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 well-structured: a concise one-line summary, followed by what it returns, then three enumerated use cases, and finally technical details. Every sentence adds value with no redundancy. The most important information is front-loaded.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains the return values (top tools, packs, volume), the data source (CF analytics-engine), privacy (no PII), and caching behavior. Sibling tools are many but this one is specialized enough that the description stands alone.

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

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

The input schema covers 100% of the single parameter with a good enum description. The tool description does not add additional parameter information beyond the schema's own description. Baseline 3 is appropriate as the description doesn't add meaning beyond what the schema already provides.

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

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

The description clearly states what the tool does: it returns top tools, top packs, and total call volume over a recent window. The verb phrase 'What other AI agents are calling on Pipeworx right now' is specific and informative, distinguishing it as a trending/aggregation tool. While not explicitly differentiating from siblings, the purpose is unmistakable.

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

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

The description provides three explicit use cases (discovering hot data sources, confirming canonical tool, checking alignment) that guide when to use this tool. It does not explicitly state when not to use or offer alternative tools, but the listed use cases give strong contextual 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 read-only, idempotent, non-destructive behavior. The description adds significant behavioral context: two modes, semantic similarity (Jaccard ≥0.30), partition filtering, and response structure. 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 with the core purpose front-loaded, followed by clear mode explanations. It is dense but not overly verbose; however, some technical details (e.g., Jaccard threshold, partition filter) could be moved to parameter descriptions for brevity.

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 complex tool with two optional parameters and no output schema, the description provides adequate context: explains both modes, response structure, and key filters. It lacks explicit mutual exclusivity of parameters and examples, but overall is complete enough for correct invocation.

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

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

Input schema descriptions cover 100% of parameters with brief explanations. The description expands on these, detailing how event and topic modes work, including cross-event search and filtering logic. This adds meaningful context beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes two modes (event and topic) and explains their use, differentiating it from sibling tools like polymarket_edges and polymarket_kalshi_spread.

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

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

The description explains when to use each mode: event mode for a single event slug, topic mode for a seed question across events. It notes that cross-event mode catches patterns missed by single-event mode. However, it does not explicitly compare to sibling tools or state 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?

The description goes far beyond the annotations (readOnly, idempotent, etc.) by detailing three response segments, the warning of market moves eroding edge, diagnostics for empty segments, caching at 1h, and limitations on Fed bets. No contradiction with annotations; all added detail is consistent and valuable.

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 thorough but long and dense, with technical details that could be streamlined or structured (e.g., bullet points for segments). It front-loads the purpose well but may overwhelm some agents. Every sentence adds value, but brevity could be improved.

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

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

Given no output schema, the description fully explains the response structure (by_segment, fed_candidates, _diagnostics), caching behavior, and knob interactions. It covers diagnostics for empty segments, making it highly complete for a complex tool with 9 parameters.

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

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

Schema coverage is 100% with good descriptions, but the tool description adds deeper context on parameter interactions, such as how min_partition_leg_kelly applies to per-leg Kelly in partition arbs, and the rationale behind tradeable-edge knobs (slippage_pp, min_liquidity). This adds meaning beyond 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?

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, positioning it for daily bet discovery. It distinguishes from siblings like polymarket_arbitrage and polymarket_kalshi_spread by focusing on Pipeworx-driven edges, and the 'what should I bet on today' use case is explicit.

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

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

The description implies usage for daily discovery ('what should I bet on today') and explains segments and knobs, but it does not explicitly compare to sibling tools or state when not to use this tool. Absent guidance like 'use polymarket_arbitrage for cross-exchange gaps' leaves room for ambiguity.

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=false. Description adds extensive behavioral context: response structure, safety fields, internal logic for skipped pairs, and temporal alignment. 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?

Front-loaded with core purpose, but quite dense. Every sentence adds value; could be slightly restructured for readability, but overall efficient.

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

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

Despite no output schema, the description covers response fields (leg-by-leg prices, spreads, compatibility_warning, temporal_alignment). Complex tool with two modes and safety fields; description is thorough.

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 each parameter described. Description adds value by listing topic shortcuts, explaining override behavior, and providing examples. Baseline 3, increased for extra context.

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?

Explicitly states cross-venue spread between Kalshi and Polymarket for the same resolving question. Clearly describes two modes (topic and explicit) and distinguishes from siblings like polymarket_arbitrage. Specific verb+resource with scope.

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 for both modes and warns when spreads are not meaningful via compatibility_warning and temporal_alignment. States 'pre-mapped ≠ tradeable' and explains conditions for meaningful usage.

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

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

Adds behavioral context beyond annotations (listing all keys, scoping to identifier, pairing with remember/forget). 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?

Front-loaded with purpose, three focused sentences, no waste.

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, usage, scoping, and pairing. Lacks return format but acceptable given no 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 already describes the parameter fully (100% coverage). Description echoes the same info, adding no new 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?

Description clearly states it retrieves a value by key or lists all keys, distinguishing it from sibling tools 'remember' (save) 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 when to use (look up stored context) and provides scoping info, but lacks explicit when-not or alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description adds valuable context: parallel fan-out to multiple sources (SEC, GDELT, GNews, USPTO), fallback logic, and return format (structured changes grouped by source, total_changes count, 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 well-structured with a clear front-loaded purpose and example queries. It is relatively long but every sentence adds value, covering behavior, parameters, and return format. Could be slightly trimmed but 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 3 parameters and no output schema, the description provides comprehensive context: parallel fan-out, fallbacks, soft-fail, return format (grouped changes, total count, citation URIs), and clear parameter explanations. The agent has enough information 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?

Schema description coverage is 100%. The description adds meaning: explains 'since' accepts ISO date or relative shorthand with examples, 'value' can be ticker or CIK, and 'type' is only 'company'. It also suggests typical values like '30d' or '1m'.

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 starts with a clear purpose: 'What's new with a company in the last N days/months?' and provides specific example queries. It distinguishes the tool from sibling 'entity_profile' by explicitly stating when to use one over the other.

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

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

The description explicitly states when to use this tool (e.g., 'what's happening with X', 'updates on Y', change-monitoring) and when to use an alternative ('Use entity_profile instead when you want the static profile'). It also explains the behavior with fallbacks and soft-fail.

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 basic hints, but the description adds critical context: key-value pair scoped by identifier, persistence differences between authenticated and anonymous users (24-hour expiry), and integration with recall/forget. This goes beyond annotations to fully inform the agent.

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 remarkably concise: five sentences, each serving a specific purpose (purpose, usage, storage detail, persistence, integration). No wasted words, front-loaded with the core action.

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

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

For a simple write tool with two required parameters and no output schema, the description covers all needed context: purpose, when to use, storage model, persistence, and sibling tools. Nothing essential is missing.

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 decent descriptions for 'key' and 'value'. The description adds examples like 'subject_property' and clarifies value as 'any text', but this is marginal value beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool saves data for later reuse, distinguishing it from siblings 'recall' and 'forget' by mentioning pairing with them. It specifies the verb 'save' and resource 'data the agent will need to reuse', making the purpose unmistakable.

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

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

The description explicitly says 'Use when you discover something worth carrying forward' and provides examples. It guides the agent on when to use, though it doesn't explicitly state when not to use. Strong positive guidance earns a 4.

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

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

Description adds value beyond annotations by detailing internal cascading lookups and specific return fields per type. Annotations already cover idempotency and read-only nature, so the bar is lower; description complements well.

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-organized: purpose, usage instruction, then details per type. Every sentence adds value without redundancy.

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

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

Given no output schema, the description adequately describes return fields for each type. Missing details like exact output structure or error handling, but sufficient for most use cases.

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

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

Schema coverage is 100%, so baseline is 3. The description adds examples and explains auto-disambiguation, enriching the parameter semantics beyond the schema's brief 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 needed by other tools. It specifies two entity types with concrete examples, distinguishing it from sibling tools like entity_profile which likely require IDs.

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

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

Explicitly advises 'Use FIRST when you have a name but need an ID.' It does not enumerate alternatives, but the context of sibling tools makes the guidance 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, idempotentHint, etc. Description adds that it internally calls ai_visibility_check and returns a ranked list with per-entity metrics. No contradictions.

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

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

Three sentences: purpose, mechanism, use case, return format. Front-loaded with main action. No superfluous 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?

Explains input constraints (2-8 entities), return format (ranked list with score, confidence, signal density), and use case. No output schema needed. Complete for the tool's complexity.

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

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

Schema covers 100% of parameters. Description adds extra context: first entity is treated as subject, models default to workers-ai, context disambiguates names. Adds value beyond schema.

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

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

Clearly states it compares AI visibility across multiple entities side-by-side, ranks by score, and surfaces most/least recognized. Distinguishes from sibling 'ai_visibility_check' by emphasizing multi-entity comparison 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?

Provides explicit use case ('competitive AI-marketing audits') and mentions it probes with 'ai_visibility_check'. Does not explicitly state when not to use or compare to all siblings, but context is clear enough.

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

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds significant behavioral details: composite nature across deps.dev and bundlephobia, partial failure handling with a sources_failed field, specific latency for bundlephobia's first measurement (5-30s), and return content (summary, advisories, links, alternatives). 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 information-dense and front-loaded with the core purpose. Each sentence adds value, covering data sources, usage, return fields, limitations, and failure modes. It could be slightly more structureled (e.g., bullet points for return fields) but remains efficient and clear for an agent.

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

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

Given the tool's moderate complexity (composite, two sources, partial failures) and absence of an output schema, the description provides sufficient detail on return values (summary fields like is_latest, license, bundle sizes; per-advisory details; links; alternative versions). It also explains reliability characteristics (first measurement latency, graceful degradation). This compensates well for the missing 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 coverage is 100% with descriptions for both parameters. The description adds extra clarity: scoped packages like '@types/node' are accepted, and the version parameter defaults to the latest. This provides actionable context beyond the schema's basic descriptions.

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

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

The description clearly states the tool's purpose: a composite check for npm packages, answering questions about safety, popularity, size, and cost. It specifies the verb 'scan' or 'check' and resource 'npm package'. While no sibling tool directly conflicts, it distinguishes itself by limiting to npm ecosystem and mentioning alternative tools for other ecosystems.

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

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

Explicitly states when to use: when an agent asks about safety, popularity, or size of an npm package. It notes limitations (npm only, partial failure behavior) and hints at alternatives for other ecosystems via deps.dev:version. Could be improved by naming specific sibling tools for non-npm queries, but the guidance is clear.

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

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

Annotations declare read-only, idempotent, and non-destructive behavior. The description adds details on returned fields (price, address, tenure, etc.), postcode formatting, and filter behavior, providing rich context beyond annotations.

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

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

The description is concise with two sentences that front-load the main purpose and then list details. Every sentence is informative with no waste.

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 12 parameters, full schema documentation, and no output schema, the description covers return data, filters, sorting, pagination, and postcode formatting comprehensively. It is 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?

Schema coverage is 100% with detailed parameter descriptions. The description adds extra value by noting postcode uppercase requirement, date override behavior, and default sort order, 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 it searches HM Land Registry Price Paid records for residential property sales in England & Wales since 1995, specifying filters, sorting, and pagination. It is specific and distinct from sibling tools like 'lookup_postcode'.

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 for searching property sales with various filters and includes a formatting requirement for postcodes. It lacks explicit exclusion of other sibling tools but provides 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?

The description goes beyond annotations by detailing internal mechanisms (SEC EDGAR + XBRL), return values (verdict, structured form, actual value with citation, percent delta), and performance benefits (replaces 4-6 sequential calls). Annotations already indicate read-only and idempotent, and the description aligns without contradiction.

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

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

The description is concise, with five sentences covering purpose, usage, version info, return values, and efficiency. No redundant or vague statements; every sentence adds value.

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

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

Given the single-parameter schema and no output schema, the description adequately explains functionality, output format, and domain constraints. It could be more explicit about error handling or input validation, but it is largely complete for typical 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?

The sole parameter 'claim' is well-documented in the schema with examples. The description adds value by restricting to company-financial domain, which is not in the schema. Schema coverage is 100%, so baseline is 3; the additional domain context raises the score.

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

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

The description clearly defines the tool's purpose as fact-checking natural-language claims against authoritative sources. It uses specific verbs (fact-check, verify, validate, confirm/refute) and identifies the resource (authoritative sources). The domain restriction to company-financial claims differentiates it from generic search 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 provides explicit usage cues such as 'Use when an agent needs to check whether something a user said is true' and illustrates with example queries. It also specifies supported claim types (company-financial). However, it does not list alternative tools for other claim types or explicitly state when not to use it.

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