Amtrak

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

Annotations declare readOnly=true, openWorld, idempotent, non-destructive. Description adds: probes multiple LLMs, returns per-model results, default model is free, Anthropic requires BYO key and direct payment. No contradictions; additional behavioral details provided 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 4 sentences, concise and front-loaded with core action. Every sentence adds value: primary function, default model and free tier, API key requirement, return format, use cases. No unnecessary words.

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

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

Given no output schema, description covers return structure (per-model fields + combined view). Tool complexity (4 params) is well-addressed. Use cases and behavioral details are sufficient for selection and invocation. Slight lack of error handling or cost notes on free usage, but overall complete.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning: explains 'entity' as brand/product/person/topic, lists supported models ('workers-ai', 'anthropic'), clarifies _apiKey usage, and 'context' disambiguates. Schema descriptions are present but description augments with practical 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?

Description clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100). Verb is specific ('probe', 'score'), resource is defined (LLMs, business/brand/product/topic). Distinguishes from siblings by focusing on AI visibility audits, unlike deep_research 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?

Description provides context on when to use: AI-marketing audits, pre-launch brand checks, competitive monitoring. It mentions default model is free and condition for using Anthropic (API key). While it doesn't explicitly state when not to use or list alternatives, the context and sibling tool names imply differentiation.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds that data is 'compact' and 'live from a community mirror of Amtrak's tracking feed,' which warns of potential non-official source and dynamic updates, providing value beyond annotations. No contradictions.

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

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

The description is compact with no wasted words. It includes purpose, example queries, output details, and data source in three sentences. Perfectly front-loaded with the core functionality.

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 input parameters and no output schema, the description fully explains what the tool does and returns. It covers purpose, example usage, data fields, and source context, making it complete for an 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?

The input schema has zero parameters, so description coverage is trivially 100%. The description adds value by explaining the output structure (per route: count, train numbers, worst delay), which is not in any schema (no output schema).

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

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

The description clearly states the tool provides a summary of all currently active Amtrak trains grouped by route, listing specific data (count, train numbers, worst delay). It uses a specific verb ('summary') and resource ('active Amtrak routes'), and distinguishes from siblings like amtrak_station_board (station-specific) and amtrak_train_status (train-specific).

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

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

The description implies use for national-level overviews ('how many trains are running', 'which routes have delays'), but does not explicitly state when not to use or mention alternative tools. However, the context of sibling tool names provides implicit differentiation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable context: it's a 'Live community mirror of Amtrak tracking (api-v3.amtraker.com)' and describes the output data (route, scheduled vs estimated arrival, delay, status). This goes 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 a single, efficient paragraph of 4-5 sentences. It front-loads the purpose, then provides examples, input format, output details, and source. Every sentence earns its place 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 absence of an output schema, the description sufficiently explains return fields. It covers input options, output data, data source, and example usage. It could mention default limit of 15 and error handling (e.g., invalid station code), but overall it's adequate for a simple board lookup 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% for both parameters. The description adds concrete examples of station codes and names (e.g., 'CHI', 'NYP', 'Chicago', 'Portland'), reinforcing and extending the schema descriptions, and provides a usage example.

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's a station departures/arrivals board for upcoming trains at a station, using a specific verb+resource structure. It distinguishes from sibling tools like amtrak_train_status (which focuses on a specific train) and amtrak_routes_active (which lists routes).

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 example queries (e.g., 'What trains are arriving at Chicago Union?') that imply typical usage. However, it doesn't explicitly state when not to use this tool or mention alternatives like amtrak_train_status for specific train queries, which would improve clarity.

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 nature. The description adds behavioral details like the fields returned (name, code, city/state, address, timezone, coordinates, inbound train count) and input types, enhancing transparency 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 extremely concise (two sentences plus example) with no wasted words. Purpose and key information are front-loaded, and the example aids understanding immediately.

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 parameter, full schema coverage, and annotations covering safety, the description is largely complete. It lists return fields and usage examples. A minor gap is the absence of a detailed return structure, but the list suffices.

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

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

Schema coverage is 100%, and the parameter description is already clear about code or name. The description adds an example call but no additional semantics beyond what the schema provides, so the 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's purpose: 'Amtrak station lookup by code or name' with a specific verb and resource. It distinguishes from sibling tools like amtrak_station_board (departures) and amtrak_train_status (train status) by focusing on station metadata.

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

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

The description provides example queries and usage, e.g., 'Where is the Amtrak station in Denver?' and a sample call. While it doesn't explicitly state when not to use, the examples and context with siblings give strong implicit 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 provide readOnlyHint and idempotentHint. The description adds transparency by noting the data is a community mirror that updates every few minutes, explaining data freshness and source. 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 (three sentences) and well-structured, starting with purpose, then input details, then output and data note. 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?

Even without an output schema, the description fully explains what is returned (GPS, speed, timeliness, etc.) and provides data source context. It is complete for the tool's functionality.

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

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

Schema coverage is 100%, and the description enhances the parameter 'train' with examples and additional compatible systems (Via Rail, Brightline), adding meaning beyond the schema.

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

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

The description clearly states the tool provides 'Live Amtrak train status and GPS tracking'. It uses specific verbs and resource ('status' of a train) and distinguishes from siblings like amtrak_station_board and amtrak_routes_active by focusing on individual train tracking.

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 the tool's inputs and outputs clearly, implying when to use it (to check a train's live status). However, it does not explicitly state when not to use it or suggest alternatives like other Amtrak tools, which would make guidelines perfect.

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, non-destructive. The description adds that it is fast, works on all tiers, returns structured answer with citation URIs, and routes to 5,011 tools. 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?

Well-structured with front-loaded key info, but slightly verbose (10 lines). Could be tightened without losing essential guidance.

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, description explains return format (structured answer with citations) and relationship to sibling tools. Covers all essential context for agent decision.

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

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

Schema has 100% coverage with 'question' parameter and aliases explained. Description adds value through examples of effective questions, though parameter details are not deeply elaborated beyond schema.

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

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

The description clearly states the tool routes factual questions to structured data sources, with specific examples. It distinguishes itself from siblings by emphasizing preference over web search and listing domains like SEC filings, FDA data, etc.

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 criteria (questions about current/historical data, 'what is', 'look up' etc.) and when-not-to-use (for hallucination resistance use ask_pipeworx_grounded; for broad questions use deep_research). Includes examples and notes it's the default entry point.

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. The description adds behavioral context beyond annotations: it explains the experimental routing improvement (source-preference ranking) and that it is compared against the stable router. 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 paragraph, front-loaded with the key identity and purpose. It is efficient but slightly verbose due to parenthetical examples. Every sentence adds value, but it could be tightened.

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

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

The description explains the tool's experimental routing behavior and confirms it is a full router, but does not describe the response shape, which is only referenced as 'same response shape' without elaboration. Given no output schema, this is a gap for an agent unfamiliar with ask_pipeworx.

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 parameter aliases. The description confirms the same arguments as ask_pipeworx but does not add new semantic meaning beyond what the schema already provides. 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 the beta version of ask_pipeworx, an identical universal router with candidate routing improvements. It specifies the unique feature: source-preference ranking when a source is named in the question. This distinguishes it from the stable sibling tool.

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 guides when to use this tool: 'Use it exactly like ask_pipeworx when you want the newest routing'. It contrasts with the stable router by noting results are compared for merge decisions. It also clarifies it is a full working router, not a fallback.

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 adds granular detail about the extra LLM call cost and explicit refusal reasons (e.g., 'not_in_source', 'no_tool_match'), which adds value beyond annotations.

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

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

The description is moderately long but well-organized: purpose first, then mechanism, then return format, then usage guidance. Each sentence contributes meaning, though it could be slightly tightened.

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 details the exact return fields ('answer', 'evidence', 'confidence', etc.) and refusal reasons. It covers behavior, parameters, usage context, and cost, making it highly complete for a query 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%, so baseline is 3. The description adds context that multiple parameter names (q, text, input, etc.) are aliases for 'question,' clarifying that any can be used interchangeably.

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

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

The description clearly identifies the tool as a 'Hallucination-resistant answer mode for high-stakes reads,' specifying that it extracts answers only from tool results. It distinguishes from the sibling tool ask_pipeworx by noting the extra LLM call and use case.

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 (high-stakes reads where answers must be verbatim) and when not to (casual lookups, prefer ask_pipeworx). Provides clear guidance on 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?

The description provides extensive behavioral details beyond the annotations, including classification fan-out examples, response shapes (market, analysis, evidence), safety mechanisms (low-confidence short-circuits, closed market handling), resolution rule risk, and parent event extraction. 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 overly verbose with multiple paragraphs and extensive examples. While comprehensive, it lacks conciseness and could be restructured with bullet points or sections for better scanability. The information density is high but at the cost of 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?

Given the complexity of the tool (3 parameters, no output schema, rich behavior), the description covers all essential aspects: input formats, response fields, safety checks, edge cases (closed markets, low confidence), and resolution rules. It is thorough and leaves little ambiguity.

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 each parameter. The description adds further context: for 'market' it reiterates input types, for 'depth' it explains quick vs thorough sources and default, and for 'include_raw' it details when to use true vs false. This adds meaning beyond the schema.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data. It specifies input types (slug, URL, question) and use cases ('should I bet on X'). This distinguishes it from siblings like polymarket_edges or polymarket_arbitrage 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 explicitly states when to use the tool: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It does not explicitly mention when not to use it or alternative tools, but the use cases are specific and clear enough to guide an agent.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds specific data details (10-K, FAERS, FDA, trials), off-calendar handling, sorting by primary metric, and citation URIs. 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?

Front-loaded with examples and clear structure. Every sentence contributes, though slightly lengthy. Minor improvement possible for conciseness.

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

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

Given complexity (two entity types, multiple data sources, no output schema), description covers return data, sorting, citation URIs, and efficiency claim. Comprehensive for the tool's purpose.

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

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

Schema has 100% coverage, but description enriches both parameters: clarifies data pulled per type, gives example inputs and limits (2-5 items), and explains return format. Adds substantial meaning beyond schema.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs, with specific example queries and data sources for each type. It distinguishes itself from sequential lookups.

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 'ALWAYS PREFER over sequential single-pack lookups' and provides clear context for when to use (comparison queries for company/drug). No explicit when-not usage, but guidance is strong.

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 numerous behavioral traits beyond annotations: parallel research decomposition, second-hop iteration, gap recovery, contradiction detection, semantic excerpting, expected response time, and stable citations. 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?

While comprehensive and front-loaded with critical information, the description is somewhat verbose. However, every sentence adds value, and key details are prioritized early.

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

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

Despite no output schema, the description fully explains the return structure (findings packet with evidence, confidence, source, gaps, contradictions, hops, citations) and provides timing expectations, making it self-sufficient.

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

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

The description adds substantial meaning beyond the schema; it explains the enum values for 'depth' in detail (number of facets, features per tier) and clarifies the 'question' parameter accepts broad/multi-part queries.

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 performs 'grounded multi-source research across Pipeworx's 1319 STRUCTURED data sources' and distinguishes it from sibling tools like ask_pipeworx for single lookups or current news.

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 ('best for broad/multi-part questions over structured data'), when not to use (single lookup, breaking news), and provides alternatives (ask_pipeworx). Also notes account requirements and a free alternative if not signed in.

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 non-destructive. The description adds valuable behavioral context: returns top-N relevant tools with full schemas and curated examples, and each result is ready to call without a second lookup. No contradiction with annotations.

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

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

The description is front-loaded with purpose and examples. Every sentence adds value, but it's slightly verbose with the long list of domains. Still, it earns its place by being comprehensive 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 6 parameters (all documented), no output schema, and the description's clear explanation of return format (top-N with names, descriptions, schemas, examples), the description is complete. It answers what the tool does, when to use, and what to expect.

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

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

Schema coverage is 100% so baseline is 3, but the description goes above by explaining aliases (task, q, description, search) and providing examples in the schema itself. The description reinforces the purpose of the 'query' parameter and clarifies aliases, adding meaning beyond the schema.

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

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

The description clearly states the verb 'Find tools' and specifies the resource ('by describing the data or task'). It distinguishes itself from sibling tools by explicitly noting it should be called first to see the option set, and lists many specific domains (SEC filings, FDA drugs, etc.) making its scope unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Use when you need to browse, search, look up, or discover what tools exist for...' and instructs 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This clearly indicates it's a discovery tool versus siblings that are domain-specific.

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 true and destructiveHint false. The description adds significant behavioral context: the patent data 'soft-fails until reactivated' due to USPTO API sunset, news uses a 'GDELT→GNews fallback,' and the tool fans out across multiple sources in a single parallel call. No contradictions with annotations.

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

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

The description is a single dense paragraph that efficiently covers purpose, usage guidelines, sources, return fields, and constraints. While no word is wasted, it could be slightly more structured with bullet points for readability, especially given the length. However, the information is well-organized and front-loaded with example queries.

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 (multiple data sources, fallbacks, soft-fails) and the absence of an output schema, the description is remarkably complete. It lists all return fields (cik, company_name, recent_filings, fundamentals, patents, news mentions, LEI) and their constraints (e.g., 'up to 5' filings, 'LATEST 10-K'). It also explains the patent sunset and news fallback, leaving no major 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 description coverage is 100%. The description adds meaning beyond the schema by explaining the 'type' parameter (only 'company' supported currently) and the 'value' parameter with examples ('AAPL' or '0000320193'), clarifying that names are not supported and directing to 'resolve_entity' for names. 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 provides a 'full cross-source profile of a US public company' and lists specific data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and return fields. It distinguishes from the sibling tool 'resolve_entity' by noting names are not supported, and implicitly from 'compare_entities' by focusing on single entity profiling.

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 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also specifies that names are not supported and instructs to 'use resolve_entity first if you only have a name.' This provides clear when-to-use and when-not-to-use guidance, along with an alternative 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 destructive behavior. Description adds context about clearing sensitive data. Does not mention idempotency (but that is secondary).

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

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

Three sentences, front-loaded, no filler. Each sentence serves a purpose: what, when, pairing.

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 single-param tool with annotations, the description covers purpose, usage scenario, and sibling guidance 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 already describes the 'key' parameter. Description does not add additional semantics 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?

Clear verb ('delete') and resource ('memory by key'). Distinguishes from siblings by explicitly pairing with 'remember' and 'recall'.

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

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

States precise conditions for use: stale context, task done, clearing sensitive data. Also indicates pairing with siblings for memory workflow.

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, so the safety profile is established. The description adds behavioral details (fetches page, extracts title/description/links, outputs markdown) that align with annotations. No contradictions.

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

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

The description is two sentences plus a bullet list of use cases, all front-loaded with the core purpose. 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?

With two well-documented parameters, good annotations, and no output schema, the description sufficiently explains the output format ('single text blob ready to drop at site-root/llms.txt'). It covers what the agent needs to know to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for both 'url' and 'max_links'. The description does not add additional meaning beyond the schema; it merely restates the default and max for max_links. 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 'Generate', the resource 'llms.txt file', and the purpose 'for any URL so AI crawlers can index the site cleanly'. It distinguishes from sibling tools like 'scan_competitor_ai_presence' by focusing on file generation rather than auditing overall AI presence.

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

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

The description explicitly lists three use cases: getting a client's site indexed, drafting for own project, or auditing a competitor. It does not state when to avoid using the tool, but the use cases are specific and 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 and idempotentHint, so the description's job is light. It adds the return fields (id, type, etc.), which is helpful but not critical. No contradictory information.

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

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

Two concise sentences: first states purpose and return fields, second provides usage guidance. No wasted words, front-loaded with key information.

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

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

For a simple list tool with one optional parameter, the description covers purpose, return fields, and usage. No output schema, but return fields are documented. Adequate for the task.

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

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

Schema coverage is 100%, with the single parameter 'include_inactive' already described in the schema. The description does not add further parameter meaning beyond the schema, meeting the 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 action ('List') and resource ('subscriptions'), and specifies it returns active subscriptions. However, it does not explicitly distinguish from sibling tools like 'subscribe' or 'unsubscribe', though the action is sufficiently different.

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

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

The description provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This helps the agent decide when to invoke this tool.

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

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

Annotations are all false, and the description adds valuable behavioral context: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota, and team reads digests daily. This goes beyond the annotations. It does not mention whether feedback is synchronous or async, but the added context is sufficient.

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

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

The description is concise (5 sentences) and well-structured: first sentence states purpose, then usage cases, then what to avoid, then consequences. Every sentence adds value without 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?

With 3 parameters (2 required), 100% schema coverage, and no output schema, the description is comprehensive. It explains purpose, usage, constraints, and behavioral details. No gaps remain for an agent to misuse 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%, so baseline is 3. The description adds meaning by clarifying the type enum with examples and specifying message length. It also explains the optional context parameter's purpose. This extra guidance justifies a 4.

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

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

The description clearly defines the tool's purpose: sending feedback about bugs, missing features, data gaps, or praise to the Pipeworx team. It uses specific verbs ('tell', 'describe') and resource ('Pipeworx team'), and distinguishes itself from sibling tools that are data retrieval or analysis 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 lists when to use the tool (bug, feature/data_gap, praise) and provides guidance on how to frame feedback (describe in terms of tools/packs, don't paste prompts). It also mentions rate limits and quota. However, it does not directly compare to sibling tools like ask_pipeworx for general questions, leaving some 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: data source (CF analytics-engine), no PII, caching behavior (5min-1h), and that it's self-aggregating. 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?

Every sentence earns its place: the first sentence defines output, the second lists use cases, the third explains data source and privacy. No filler, 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?

Despite no output schema, the description covers return fields (top tools, top packs, total call volume), caching, and privacy. For a read-only aggregation tool with full annotation coverage, this is sufficiently complete.

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

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

The single parameter 'window' is fully described in the schema with an enum and per-value description. The tool description adds only the usage nuance ('shorter windows surface what's hot right now; longer windows show steady-state demand'), which is helpful but ancillary. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' over configurable time windows. It distinguishes itself from sibling tools by focusing on Pipeworx-wide trending signals, not specific domains like Amtrak or Polymarket.

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

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

Three specific use cases are explicitly listed (discovering hot sources, canonical tool confirmation, alignment checking). While it doesn't explicitly mention when not to use or name alternatives, the use cases provide clear guidance for selection.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false) already declare the tool is safe and non-destructive. The description adds detailed behavioral context: how it scans markets, the semantic anchor requirement (≥0.30 Jaccard similarity), partition filter logic, fill check against live CLOB depth, and the response fields. 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 long but well-structured and efficient. It starts with the core purpose, then details invocation modes, followed by semantic anchor and partition filter details, response structure, and fill check. Each sentence adds value, though some sections 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?

Given the tool's complexity (multiple modes, response fields, dependencies on other tools), the description is complete. It covers all aspects: purpose, parameter usage, behavioral nuances, output structure (listing fields like opportunities, partition_check, fill check), and references sibling tool for custom sizing. No output schema, but descriptions compensate adequately.

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, but the description adds substantial meaning: it explains the purpose of each parameter (event vs topic), gives concrete examples of slugs and topics, and clarifies that no args triggers trending scan. It also explains what happens with each parameter in terms of tool behavior.

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 specifies three invocation modes (no args, event, topic) and distinguishes them. It references sibling tools like polymarket_edges and polymarket_fill_risk, providing context for differentiation.

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

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

The description provides explicit guidance on when to use each parameter: no args for trending scan, event for a specific market, topic for cross-event scanning. It recommends event mode for a specific market and explains that cross-event mode catches patterns missed by single-event mode. It directs custom sizing to polymarket_fill_risk, but does not explicitly exclude other scenarios.

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 annotations (readOnlyHint, idempotentHint) by detailing three model families, edge calculation formulas, tradeable-edge knobs, response structure with diagnostics, and caching behavior. It fully discloses the tool's inner workings.

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

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

The description is front-loaded with purpose and then dives into technical details. While verbose, the complexity of the tool (three models, multiple knobs) justifies the length. Some minor redundancy exists (e.g., default values repeated).

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

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

The description covers all aspects: model details, output structure, diagnostics, caching, and exclusion of Fed bets. Given 9 parameters and no output schema, it provides complete guidance for an agent to use the tool effectively.

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

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

Although schema coverage is 100% and parameter descriptions are detailed, the main description adds context by grouping knobs (e.g., tradeable-edge filters) and explaining their interaction. It avoids redundancy and adds value.

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

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

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price. It distinguishes itself from siblings like polymarket_arbitrage by focusing on three specific model families (model_driven, structural_arbitrage, concentrated_longshot) and targets daily betting decisions.

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

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

The description explicitly states the tool is 'Built for what should I bet on today' and explains how agents can discover opportunities without paging. However, it does not provide explicit 'when not to use' or compare to sibling tools like polymarket_edge_tracker or polymarket_fill_risk.

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. Description adds rich behavioral details: snapshot gap behavior (cache-miss), response structure (tracked, expired, dates), history limits (60-day TTL, daily closes). 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?

Packed with useful information, front-loaded with the key question. Slightly verbose but each sentence adds value. Could be slightly tighter.

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

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

No output schema, but description explains response structure thoroughly (tracked[], expired[], snapshot_dates[]) and covers limits and caveats. Missing some details on trend interpretation but sufficient for agent decision.

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 both parameters with 100% coverage. Description reinforces defaults and acceptable values but adds marginal new meaning beyond schema (e.g., explaining window as 'snapshot family').

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 defines tool as edge persistence/decay telemetry from daily snapshots, answering a specific question about edge age and decay. Distinguishes from sibling polymarket_edges which likely provides current snapshots.

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 context about when to use this tool (checking edge age) implying difference from fresh vs old edges. Does not explicitly name alternatives but the sibling list suggests it's the go-to for temporal analysis.

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. Description adds operational context: walks the ladder, returns specific fields like slippage_pp, max_fillable_usd, and warns about forced_directional_risk. 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 thorough but verbose, around 150 words. It is front-loaded with purpose but includes detailed technical explanation that could be more structured or abbreviated. Adequate for complexity but not 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?

Despite no output schema, description enumerates all return fields for both modes, explains risks (thin_legs, forced_directional_risk), and provides context on when it is needed. Fully compensates for lacking output schema given tool 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%, baseline 3. Description adds meaning beyond schema by explaining mode selection (market vs event), side defaults per mode, and different interpretations of size_usd (spend vs target proceeds for single-market, settlement notional for basket).

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 performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' with explicit single-market and basket modes, and specifies return fields. It distinguishes from siblings by directing usage before polymarket_arbitrage and polymarket_edges.

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

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

Explicitly says when to use: 'before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Explains why alternatives fail: theoretical overround on thin books is not capturable, and partial basket fills convert an arb into directional risk.

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 readOnlyHint annotation, the description details exact response structure (leg-by-leg prices, top_spreads_pp), safety fields (compatibility_warning conditions, temporal_alignment, skipped counters), and edge cases like non-equivalent bet shapes or temporal misalignment. This transparency greatly aids correct interpretation.

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

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

The description is front-loaded with the core purpose, then logically progresses through modes, safety fields, and caveats. While fairly long, it is dense with useful information and avoids redundancy. A slightly tighter summary could improve conciseness, but it remains well-organized.

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

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

Despite lacking an output schema, the description thoroughly explains the response: leg-by-leg prices, matched spreads with top_spreads_pp, and detailed safety fields. It covers interpretation of compatibility_warning and temporal_alignment, making the tool's output fully understandable without additional documentation.

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 already describes all three parameters with 100% coverage. The description adds value by listing the exact pre-mapped topic values, explaining the overriding behavior of explicit tickers, and providing examples. This extra context helps the agent use parameters correctly 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 begins with 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' clearly stating the verb (computes spread) and specific resources (Kalshi and Polymarket). It distinguishes from sibling tools like polymarket_arbitrage by emphasizing the cross-venue nature, and the two modes further clarify its 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?

The description explains two usage modes (topic shortcuts vs. explicit tickers) and warns that pre-mapped topics often yield compatibility warnings, implying explicit tickers are more reliable. It provides guidance on interpreting safety fields (compatibility_warning, temporal_alignment) to know when spreads are meaningful. However, it lacks an explicit 'when not to use' or direct comparison to similar tools, though context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destrictiveHint. The description adds value by explaining the scoping behavior (per identifier) and the conditional behavior when the key is omitted (list all keys). 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 very concise (three sentences) with no wasted words. It front-loads the core purpose and immediately provides concrete use cases. Every sentence adds value.

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

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

Given the tool's simplicity (one optional parameter, obvious outputs), the description covers all needed aspects: retrieval vs listing, scoping, and pairing with sibling tools. Annotations cover safety, so no additional behavioral details are necessary.

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

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

Schema coverage is 100% with a clear parameter description. The description reinforces the parameter's behavior (omit to list all) and adds context about saving via remember, but does not add crucial new semantic 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 it retrieves a saved value (specific verb: 'Retrieve') and distinguishes between retrieving a specific key and listing all keys. It also provides concrete examples like user's target ticker, address, research notes, and explicitly contrasts with sibling tools remember and forget.

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

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

The description provides explicit usage context: 'Use to look up context the agent stored earlier' and explains the scope ('scoped to your identifier'). It implicitly tells when not to use by suggesting alternatives like remember and forget. While it lacks explicit 'when not to use' statements, the context is clear enough for the agent.

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

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

Description describes mark_read as a side effect that mutates state (flags events as read), but annotations declare readOnlyHint=true, creating a direct contradiction. No other behavioral disclosures compensate.

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

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

Five sentences, no filler. Front-loaded with purpose, then parameter details and use-case notes. 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?

With rich annotations covering safety and idempotency, the description completes the picture: explains return structure (source, citation_uri, raw payload), provides usage context, and mentions an alternative access method. No gaps 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 coverage is 100%, baseline 3. Description adds value by giving an example filter value ('sec_8k') and clarifying the ISO timestamp format for 'since', plus explaining the purpose of 'mark_read'. Does not cover 'limit' or 'unread_only' 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 'Pull fired events from your subscription feed' with specific verb and resource. Distinguishes from siblings by focusing on subscription alerts; no overlapping sibling tool exists.

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 context: filtering options, polling compatibility, and an alternative HTTP endpoint for scripts/dashboards. Does not explicitly state when not to use, but the alternative implies it.

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 explains fallback behavior between GDELT and GNews, USPTO soft-fail, and return structure, all of which go beyond the annotations that only indicate it is read-only, open-world, and idempotent.

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 dense but front-loaded with example queries, making it efficient. However, a slight structuring (e.g., bullet points for sources) could improve readability.

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

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

Despite lacking an output schema, the tool description fully compensates by detailing the return structure (grouped changes, total count, citation URIs) and covers all key behavioral aspects.

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 schema coverage is 100% with descriptions for each parameter, the tool description adds valuable context like example values and typical monitoring intervals, enhancing understanding beyond the schema.

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

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

The description clearly states the tool provides a change feed for a company, listing specific data sources and differentiating itself from the sibling tool 'entity_profile' which returns static profiles.

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 example queries ('What's new with X', etc.) and directly advises when to use the alternative tool 'entity_profile' instead of this one.

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 and non-destructive. Description adds context about scoping by identifier and TTL (24 hours for anonymous), which is helpful but not critical.

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

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

Single paragraph, front-loaded with purpose, every sentence adds value. No redundant 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 simple structure (2 params, no output schema), the description covers purpose, usage, behavior, and persistence 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 has 100% coverage, but description adds concrete examples of key names and values, 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?

Clearly states the tool saves data for later reuse, distinguishes from siblings recall and forget. Verb 'save' and resource 'data' are specific.

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

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

Provides explicit when-to-use examples like resolved ticker, target address, etc. Also mentions scoping and persistence durations, and pairs with recall/forget.

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. The description adds significant behavioral context: 'cascades through several lookup endpoints internally' and specifies exact return fields (ticker, CIK, company_name, citation URI for company; RxCUI, ingredient, brand for drug). 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 relatively long but well-structured: examples first, then core purpose, usage recommendation, type details. Every sentence adds value, 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?

Despite no output schema, the description explains return structures for both types, including citation URIs. It covers input variations and internal cascading behavior. The tool's purpose is simple and fully described.

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. The description enhances this by providing real-world examples (e.g., 'ozempic', 'metformin') and clarifying auto-disambiguation. It adds meaning beyond the schema's terse 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 starts with specific example queries and clearly states the tool resolves names to canonical identifiers. It lists supported entity types (company, drug) and differentiates from siblings by being the go-to for name-to-ID resolution.

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 whenever you have a name but need an ID', giving clear when-to-use guidance. It also details per-type input expectations. It does not explicitly state when not to use, but the 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 indicate readOnly, idempotent, openWorld. Description adds that it probes each entity and returns ranked scores, but does not detail side effects or auth consequences beyond the API key note.

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 concise sentences: main action, mechanics, use case. No redundant or verbose language. Front-loaded with key verb 'Compare'.

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 mentions return components (score, confidence, signal density) adequately. Lacks details on error handling or edge cases, but sufficient for an 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?

Schema coverage is 100% with parameter descriptions. Description adds semantic value by noting that the first entity is treated as the 'subject' for narrative, and clarifies the optional API key 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?

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using ai_visibility_check and ranking by score. It differentiates from sibling ai_visibility_check by focusing on multi-entity comparison.

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

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

Provides a concrete use case (competitive AI-marketing audits) and example question. Does not explicitly mention when to avoid or compare to siblings like compare_entities, but the purpose is clear enough for typical 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?

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds timing details (bundlephobia first measurement 5-30s), graceful degradation with sources_failed list, and the composite nature. No contradiction with annotations.

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

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

Description is dense yet well-structured, front-loading the purpose. Every sentence adds value, no redundancy. It efficiently covers purpose, usage, and behavior.

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 details the return format (summary block, advisories, links, alternative versions) and partial failure handling. Adequate for a composite tool with two 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 descriptions for both parameters. The description adds value by clarifying that scoped packages are accepted and that version defaults to latest, providing context beyond schema.

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

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

The description clearly states it is a composite check for npm packages covering safety, popularity, and size via deps.dev and bundlephobia. It distinguishes from siblings by focusing on npm ecosystem, unlike tools like scan_competitor_ai_presence.

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

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

Explicitly instructs to use when agent asks about safety/popularity/size of an npm package, and notes that PyPI/Maven/Cargo/Go are not supported in v1, directing to deps.dev:version directly. Also explains partial failure behavior.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds critical behavioral details: truncation at 200K chars (flagged), embedding model (BGE-base-en), window size (500-char overlapping), cosine similarity, and return format (offsets and scores). This fully informs the agent about performance and limitations.

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 (3 sentences) and front-loaded with the key purpose. Every sentence adds unique value: purpose, use case, technical detail. No redundant 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 has no output schema, the description adequately explains return values (passages, offsets, scores). Combined with annotations for safety and idempotency, the description covers all key aspects: what it does, when to use, behavioral details, and pairing guidance. No gaps remain.

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 specifying the max length for 'text' (~200K chars), providing examples for 'query', and implicitly defining 'limit' range. However, it omits explicit defaults for 'limit' (though schema says default 5) and does not clarify truncation behavior during truncation.

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: 'Semantic search INSIDE a fetched record.' It specifies the action (search inside), the resource (a fetched record), and the scope (top-N passages with offsets and scores). It distinguishes itself from generic search tools by focusing on already-retrieved text and providing character offsets.

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: 'Use when the record is too big to cram into the prompt.' It also explains the benefit (saves context) and pairs with ask_pipeworx_grounded for grounded QA. This clearly tells an agent when to choose this tool over 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?

Adds significant behavioral context beyond annotations: returns subscription ID, delivery channels, SMS caps, webhook signing, auto-disable after failures. No contradiction with annotations (write operation, idempotent hint is consistent).

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?

Fairly long but every sentence adds value. Well-structured with bullet points. Could be slightly more concise but not wasteful.

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 most necessary context: subscription types, delivery channels, constraints. Does not explicitly mention subscription destruction behavior, but output schema not required. Adequate for a complex 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?

Enriches schema descriptions with concrete examples for each subscription type's params (e.g., sec_8k items codes) and delivery details (webhook secret returned once). Even though schema coverage is 100%, description adds practical meaning.

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 creates a proactive monitoring subscription to a live-data event stream. It uses specific verb+resource (create subscription) and distinguishes from siblings like list_subscriptions and unsubscribe.

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: for persistent monitoring of specific event types. Includes prerequisites (Pipeworx OAuth account) and examples for each type. Implicitly excludes anonymous/BYO users. Lacks explicit 'when-not-to-use' but context is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context by explaining it is an onboarding entry point, the return format (category-bucketed questions with tool shapes), and that it draws from the live catalog. This provides value 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?

The description is well-structured with a clear purpose upfront, followed by examples and usage. While slightly long, every sentence contributes value, explaining return content and use cases. It could be tightened but is efficient overall.

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 sufficiently explains what the tool returns: category-bucketed example questions with exact tool and argument shapes. It covers the tool's role in onboarding and learning about meta-tools, making it complete for a simple exploration 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 one optional parameter. The description clarifies that omitting the topic gives a full spread and lists example valid values (e.g., finance, pharma). It adds meaning beyond the schema's description of 'Optional focus area'.

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 specifies the tool returns category-bucketed example questions for Pipeworx, clearly distinguishing it from siblings like ask_pipeworx and discover_tools. The verb 'Returns' and the resource 'example questions' are specific, and the context of onboarding is clear.

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: 'Call with no arguments for the full spread, or pass topic... Use this FIRST when you do not yet know what Pipeworx can do for you.' Also mentions learning to call meta-tools, providing clear context and 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?

Goes beyond annotations by explaining ownership enforcement, deactivation (not deletion), and that historical events persist via recent_alerts. 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?

Two concise sentences that front-load the core action. No filler words, every sentence adds value.

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

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

Given only one required param, no output schema, and rich annotations, the description covers all key aspects: action, ownership, side effects, and data persistence. Fully complete for this 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 provides full description for param 'id', and description adds context that it is the id returned by subscribe, adding meaning beyond 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?

Description clearly states the verb 'Cancel' and the resource 'subscription by id', with specific ownership enforcement and deactivation behavior. Distinguishes from siblings like subscribe and list_subscriptions.

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 when to use (cancel own subscription) and mentions ownership constraint, but does not explicitly list conditions for when not to use or compare with alternatives. Still 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 indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context: it returns a specific verdict enum, uses citations, and explains the two processing pipelines. No contradictions with annotations. The description enhances transparency by detailing the internal logic beyond what annotations provide.

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 relatively long but well-structured, starting with query patterns and ending with output details. While every sentence adds information, the content could be more concise (e.g., the note about replacing 4-6 calls is non-essential for tool selection). It is not tautological but could benefit from trimming.

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, the absence of an output schema, and the presence of many sibling tools, the description is comprehensive. It covers input format, processing logic, output structure (verdict types, citations, actual values), and even highlights efficiency gains. No notable gaps remain for safe 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%, with clear descriptions for both parameters. The description reinforces the claim parameter with examples and explains the tolerance_pct's purpose and default behavior, but does not add significant new meaning beyond the schema. Baseline 3 is appropriate as the schema already does the heavy lifting.

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

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

The description clearly states the tool's purpose: validating factual claims against authoritative sources. It provides specific verb-resource pairing ('verify claim') and distinguishes itself from sibling tools by focusing on fact-checking. The inclusion of example query patterns reinforces its 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?

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It also distinguishes two processing paths (financial vs. other claims), giving clear context. However, it does not explicitly state when not to use the tool or list alternatives beyond implicit sibling differentiation.

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