Ai Briefing

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

Adds value beyond annotations by describing the free default model, BYO key for Anthropic cost implications, and per-model return structure. Aligns with readOnlyHint, openWorldHint, idempotentHint, and destructiveHint.

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 with core purpose, then key details, then return structure and use cases—every sentence serves a purpose.

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

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

Despite no output schema, the description adequately details return fields and use cases, making it complete for a tool with 4 simple 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?

With 100% schema coverage, the description enriches meaning by specifying the default model, the conditional requirement for _apiKey, and the disambiguation role of 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 probes LLMs for knowledge about an entity and scores visibility 0-100 per model, distinguishing it from sibling tools like deep_research or entity_profile.

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

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

Explicitly mentions use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and implies when to use by contrasting with alternatives, though no explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds behavioral context beyond annotations: routes to one of 5,529 tools, fills arguments, returns stable pipeworx:// citations, works on every tier, and is a single fast call. No mention of rate limits or edge cases, but the annotation coverage lowers the bar, and the added routing/citation behavior is useful.

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 front-loaded with the most critical guidance ('PREFER OVER WEB SEARCH', 'START HERE'). Each sentence adds value: domain list, routing mechanism, examples, step-up alternatives. Slight redundancy in the long list of trigger phrases and examples, but overall it is efficiently organized and purposeful for a complex router tool.

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

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

For a tool with no output schema, the description explains the return format (structured answer with citations) and the scope. It covers when to use, when not to use, alternatives, and examples. Given the tool's complexity (routing across 5,529 tools), this is a complete description for an agent to decide and invoke confidently.

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%: all parameters are documented, with question having five aliases. The description adds example questions but no additional parameter syntax or format details beyond what the schema provides. Per baseline, a 3 is appropriate when 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?

Description clearly states ask_pipeworx is a routing/answering tool for factual questions over structured data, with specific verb ('ask') and resource (Pipeworx). It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by positioning itself as the default entry point. The scope is explicit: current/historical data across numerous domains, returning structured answers with citations.

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?

Uses strong directives: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions'. Gives explicit trigger phrases and examples ('what is', 'look up', 'find', etc.). Provides exclusion/step-up guidance: use ask_pipeworx_grounded for hallucination-resistant single answers, deep_research for broad/multi-part questions, and clarifies news/breaking-news handling. This is model behavior for usage guidance.

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

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

The description discloses the experimental nature, live candidate routing, the current inactive state, and that it matches ask_pipeworx exactly. This goes beyond the provided annotations (readOnly, openWorld, idempotent, non-destructive) by explaining the comparison mechanism and fallback behavior, without contradicting them.

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

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

Four dense sentences, each earning its place: beta status, identity, current state, usage, and fallback. No fluff, well-structured, and front-loaded with the most important information.

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

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

Despite lacking an output schema, the description explains the current behavior and points to the stable router's response shape. It's sufficient for an agent to decide when to use this beta variant, though it relies on prior knowledge of ask_pipeworx for full understanding of return values.

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

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

Input schema has 100% coverage with all six parameters documented as aliases for 'question'. The description adds no extra parameter-specific detail beyond stating 'same arguments' as ask_pipeworx, so the schema already does the heavy lifting. 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 identifies the tool as a beta version of ask_pipeworx, a universal router with the same 5,529 tools and arguments. It explicitly distinguishes it from the stable sibling by mentioning candidate routing improvements, giving a specific and clear purpose.

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

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

It explicitly instructs 'Use it exactly like ask_pipeworx when you want the newest routing,' and notes that results are compared against the stable router. This provides clear when-to-use guidance and implicitly contrasts with the stable alternative.

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

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

Annotations already declare readOnly, openWorld, idempotent, and destructiveHint=false. The description adds rich behavioral context: the extra LLM call cost, the deterministic refusal reasons (not_in_source, no_tool_match, etc.), the verbatim evidence extraction, and the routing mechanism. No contradiction with annotations.

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

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

Four sentences, front-loaded with the core purpose. Each sentence adds value: mode, routing, output structure, usage guidance, and cost tradeoff. No wasted words.

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

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

With no output schema, the description fully specifies the return shape for success and failure, including refusal reason enums. It covers cost impact, use cases, and alternatives. This is a complete description for a single-question 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% (all 6 params are aliases for 'question'), so baseline is 3. The description does not add parameter-specific meaning, but the parameter is a simple free-text question; the schema's alias descriptions are self-explanatory.

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, with a specific verb ('EXTRACTS') and resource (routing across 5,529 tools/1,455 sources). It explicitly contrasts itself with ask_pipeworx, distinguishing the grounded extraction behavior and refusal handling.

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 usage criteria: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' It also gives a clear alternative by saying 'prefer ask_pipeworx for casual lookups.' This is model usage guidance.

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

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

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description extensively discloses behavior: low-confidence resolutions short-circuit with status, closed/dead markets return 'market_closed_or_inactive', wide-spread markets carry tradeability flags, and cancellation rules are parsed. It also explains resolver contract, parent event extractor, and news field fallback logic, providing comprehensive transparency.

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

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

The description is verbose with multiple paragraphs and capitalized sections. While well-structured and front-loaded with the core purpose, it contains extensive details (e.g., cancellation rule parsing, news fields) that could be condensed. Not every sentence is essential for an AI agent to select and invoke the tool.

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

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

Without an output schema, the description thoroughly explains return shapes: result.market, result.analysis, result.evidence, resolver contract, parent event, news fields, and edge cases (low confidence, closed markets, wide spreads, cancellation rules). It covers all necessary behavioral and response details for correct usage.

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

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

With 100% schema description coverage, the description adds significant meaning: it explains the three accepted input formats for 'market', the 'depth' enum values ('quick' vs 'thorough' with default), and 'include_raw' flag behavior (summarized vs full payloads). This contextualizes parameters beyond the schema, aiding correct invocation.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, specifying input formats (slug, URL, question text) and actions (resolve, classify, fan-out, return evidence packet and comparison). It distinguishes from sibling tools like polymarket_edges or polymarket_arbitrage by focusing on comprehensive research for a single bet.

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

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

The description explicitly states use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. It provides detailed fan-out examples by category, offering clear context. However, it does not specify when not to use the tool or mention alternatives beyond the implicit differentiation from sibling tools.

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

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

Annotations confirm read-only, idempotent, non-destructive behavior. The description adds substantial behavioral details: results sorted by primary metric, correct handling of off-calendar fiscal years, return of citation URIs, and efficiency claim (replaces 8–15 sequential lookups). 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 natural language queries and packs detailed behavior into a dense paragraph. Every sentence adds value, though slightly lengthy; could be tightened slightly 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 fully covers the return format (paired data with citation URIs), data sources, sorting behavior, and edge cases (off-calendar fiscal years). It leaves no major gaps for an agent to understand the tool's capabilities.

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

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

Schema coverage is 100%, but the description adds significant meaning: clarifies that type='company' pulls 10-K data from SEC EDGAR/XBRL with precise fields, while type='drug' pulls FAERS, FDA approval, and trial counts. It also explains the required format for values (tickers/CIKs for companies, names for drugs).

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 lists clear user queries ('Compare X and Y', 'X vs Y', 'rank these companies') and explicitly states the tool performs side-by-side comparison of 2–5 companies or drugs, distinguishing it from sibling tools like entity_profile that likely handle single entity 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?

The description explicitly instructs 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear when-to-use guidance and implicitly recommending this tool over iterative single-entity calls.

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 behavior. The description adds substantial context beyond this: account/sign-in requirements, free vs paid tier implications, return packet contents (verbatim evidence, confidence, source, fetched_at, citations), gap reporting and the guarantee of never inventing answers, contradictions scan, semantic excerpting behavior, latency expectations, and the conditional presence of citation_uri. 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 long but densely informative, covering auth, use cases, alternatives, mechanics, output, and latency. Every sentence carries unique value; however, it could be tightened without losing substance. Structure is logical, moving from requirements to capability to usage guidance to technical details.

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

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

Given the tool's complexity, lack of output schema, and rich sibling set, the description is highly complete. It explains the full return packet, gaps[] and contradictions[] fields, citation URI behavior, semantic excerpting, latency, account prerequisites, and when to prefer alternatives. No critical gaps remain for an agent to select and invoke 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 description coverage is 100%, so the baseline is 3. The description adds extra nuance: the depth parameter's effect on gap recovery and iterative hops ('standard re-angles unanswered gaps... thorough additionally chases the best leads'), and clarifies the question parameter accepts broad/multi-part questions. This goes beyond schema but is somewhat redundant with the already detailed schema descriptions.

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

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

The description states a specific verb+resource+scope: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources' in a single call, with decomposition into facets and parallel routing to 5,529 tools. It clearly distinguishes from siblings like ask_pipeworx by noting it is 'NOT open-web search' and by contrasting use cases.

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 when-to-use and when-not-to-use guidance is provided: 'Best for broad/multi-part questions over structured data,' with explicit alternatives named ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'). Account requirements and fallback behavior (use ask_pipeworx if not signed in) are also clearly stated.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description fully aligns, describing a non-destructive, read-only lookup. The description adds that results are 'ready to call directly, no second schema lookup needed,' which provides valuable behavioral context beyond annotations.

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

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

The description is front-loaded with the core purpose and provides a comprehensive list of example domains. It is slightly verbose but every sentence adds value. Could be trimmed slightly, but it's well-structured and informative.

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

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

Given the tool has 6 parameters with 100% schema coverage and no output schema, the description is complete: it explains the function, input format, output content (names, descriptions, schemas, examples), and usage context. No gaps remain for effective invocation.

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

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

Schema description coverage is 100% with detailed descriptions for all 6 parameters, including aliases and examples. The description does not add significant meaning beyond the schema, as it only briefly mentions that the query is a 'natural language description.' Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists many example domains and explains that it returns top-N most relevant tools with full schemas and examples, distinguishing it from siblings which are specific data tools. The verb 'discover' and resource 'tools' are specific and accurate.

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

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

The description explicitly advises when to use: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It also implies when not to use (when you already know the tool or need a single answer). This provides clear context for selection among siblings.

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

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

Annotations provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds behavioral details: fans out across multiple sources, returns specific data fields, notes patent soft-failure after May 2025. Minor omissions like rate limits or error handling, but adds significant value.

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 dense paragraph. While front-loaded with examples, it could be better structured with bullet points. It is not overly long but packs many details into one block.

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 return fields (CIK, filings, fundamentals, patents, news, LEI) and limitations (patents sunset, US-only). Adequate for a complex profile tool, though some error handling details are missing.

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

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

Schema covers both parameters fully (100% coverage). Description reinforces meanings: 'value' can be ticker or zero-padded CIK, names not supported; 'type' is 'company' with future plans. Adds clarity beyond schema.

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

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

Description clearly states it provides a full cross-source profile of a US public company in one call, with specific examples like 'Tell me about X' and lists sources (SEC EDGAR, XBRL, etc.). It distinguishes itself from sibling tools like resolve_entity and compare_entities.

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

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

Explicitly advises 'ALWAYS PREFER over chaining single-pack lookups when the user asks for a holistic view.' States to pass ticker or CIK, not names, and directs to use resolve_entity first for names.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive action. The description adds no new behavioral context beyond confirming deletion. With annotations present, a 3 is appropriate.

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

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

Two sentences with no wasted words. Every sentence adds value: first states purpose, second gives usage context. Front-loaded clearly.

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, no output schema, and annotations covering safety, the description is complete. It states what it does, when to use it, and how it relates to siblings.

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% for the single parameter 'key', which is described as 'Memory key to delete' in the schema. The description does not add any additional detail about parameter format, constraints, or validation, 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 'Delete a previously stored memory by key.' It specifies the verb (delete), resource (memory), and scope (by key), and distinguishes from sibling tools 'remember' and 'recall' by pairing them.

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

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

The description provides explicit usage scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' It also advises pairing with related tools but does not explicitly state when not to use it, though the positive 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?

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it fetches the page, extracts content, and outputs standard llms.txt format. It does not detail error handling or rate limits but adds meaningful behavioral context beyond annotations.

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

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

Three sentences: purpose, process, and use cases. Front-loaded with purpose, no redundant information, every sentence earns its place.

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

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

For a simple tool with 2 parameters and no output schema, the description covers input, output format, and use cases. It lacks error handling details but is sufficient for an AI agent to understand the tool.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description references the parameters indirectly (e.g., 'extracts title/description/key links') but does not add new meaning beyond the schema.

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

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

The description clearly states the tool generates an llms.txt file for a given URL, specifying the action and resource. It distinguishes from sibling tools like scan_competitor_ai_presence by focusing specifically on llms.txt generation.

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

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

The description provides explicit use cases (e.g., indexing client sites, drafting for own project, auditing competitor visibility) but does not mention when not to use or compare alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and behavior. The description adds that the tool returns events with dates and summaries, which is consistent but does not elaborate on rate limits, authentication needs, or data freshness. With high annotation coverage, this is adequate but not exceptional.

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: one sentence defining the purpose and one sentence on return format. Every part is necessary and front-loaded. No filler or redundancy.

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

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

For a simple read-only tool with two optional parameters and an output schema, the description covers the core function and output. It could mention default parameter values (though schema examples do), but overall it provides sufficient context for an agent to invoke 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 description coverage is 100%, with both 'days' and 'limit' already documented. The tool description does not add any additional meaning about these parameters, so it neither improves nor degrades the semantic clarity. Baseline score 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 retrieves AI industry news and lists specific content types (model releases, funding, etc.). It uses a specific verb and resource combination, making the purpose unambiguous. While it does not explicitly distinguish from siblings like get_recent, the scope is well-defined enough for an agent.

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

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

The description implies usage for broad AI news but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_recent or entity_profile). No when-not conditions or references to sibling tools are given, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context on return content (new capabilities, categories), which is useful but not critical given the annotations.

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

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

Two sentences with zero waste. Front-loaded with the core purpose, then lists examples of returned content. Efficient and easy to parse.

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

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

Given the simple tool with two optional parameters and an existing output schema, the description provides sufficient context about what the tool returns and why to use it, without needing to explain return format.

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 two optional parameters (days, limit) with defaults. The description adds no additional meaning or usage nuance for parameters.

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 action 'Get' and resource 'latest available tools', listing specific categories like 'Claude Code features, MCP servers, SDK updates' which differentiates it from sibling tools like 'get_ai_news' or 'discover_tools'.

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

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

The description implies usage for discovering new tools since the model's training cutoff, but does not provide explicit guidance on when to prefer this tool over siblings (e.g., discover_tools, get_ai_news) or when not to use it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by specifying the type of content returned (new MCP servers, APIs, SDKs, frameworks with summaries and URLs), which informs the agent of the output structure 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?

Single sentence front-loaded with purpose, no extraneous words. Efficiently conveys all necessary 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 one optional parameter with full schema coverage, rich annotations, and an output schema, the description is complete. It explains what the tool returns and the parameter's role, leaving no gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description mentions the date parameter and its default, but this is already covered in the schema's description field. No additional semantic meaning added.

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

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

Description clearly states verb 'Get', resource 'daily AI tools digest', and scope (given date, default today, last 24 hours). Distinguishes from siblings like get_ai_news or get_recent by specifying it's a curated digest of new MCP servers, APIs, SDKs, and frameworks.

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?

Clear context: use to get a daily curated list of new AI tools for a specific date. Does not provide explicit when-not-to-use or alternative sibling tools, but the context is sufficient for an agent to decide.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. The description adds value by detailing the return structure (grouped by importance, fields returned). No contradictions. The description could mention pagination or limits, but given annotations, it is sufficient.

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

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

Two concise sentences: purpose first, then specifics. No wasted words. Front-loaded with action and scope.

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 a simple tool with one optional parameter, comprehensive annotations, and an output schema (not shown but exists), the description fully covers the tool's functionality and return values. No gaps.

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

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

Schema coverage is 100% with one parameter ('days') well described. The description repeats the default but adds no further semantic detail. Baseline 3 applies as schema does the heavy lifting.

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

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

The description uses a specific verb ('List') and identifies a clear resource ('AI model releases from the last N days') with a default. It distinguishes from siblings like get_ai_news by specifying the focus on model releases and return fields.

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

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

The description implies usage for recent model releases but does not explicitly state when to use versus alternatives (e.g., get_ai_news for general news) or provide exclusions. The context is clear but lacks comparative 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. Description adds filtering capabilities and default days, but does not disclose potential caveats like data freshness limits, pagination, or rate limits. Adds moderate 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?

Single sentence is extremely concise, front-loaded with the core action and scope, and contains no redundant or unnecessary words. Every element serves a purpose.

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

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

Description covers key features (time range, filters, defaults) and is supported by a complete output schema. Slightly lacks detail on default ordering or pagination behavior, but overall sufficient for a filtered retrieval tool.

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

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

Schema coverage is 100% with clear descriptions and examples for all 5 parameters. Description mentions days, category, source, and importance but adds no new semantic detail beyond what the schema provides. 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?

Description clearly states verb 'Retrieve', resource 'AI developments', and temporal scope 'last N days' with filtering options. Distinguishes from siblings like 'deep_research' and 'get_ai_news' by focusing on recency and structured filtering, but lacks explicit differentiation.

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

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

Implied usage for retrieving recent AI developments, but no explicit guidance on when to use this tool versus alternatives (e.g., 'get_ai_news', 'search_developments'). No exclusions or when-not scenarios provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that results are ordered by date and include descriptions, which is helpful but adds only moderate behavioral context 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 two concise sentences, front-loaded with the core action and resource, followed by details on ordering and purpose. No wasteful words.

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

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

Given the tool has an output schema and the description covers the essential purpose and result characteristics (chronological order, descriptions), it is mostly complete. Minor omission: it doesn't specify the source or scope of 'AI developments', but that's implied by the tool context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond what is already in the schema.

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

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

The description clearly states it retrieves a chronological timeline of AI developments between two dates, with events ordered by date and descriptions. This distinguishes it from siblings like get_ai_news or get_recent, though it doesn't explicitly differentiate.

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

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

No guidance is provided on when to use this tool versus alternatives. It lacks instructions on when not to use it or which sibling tools might be more appropriate for 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?

Annotations already indicate read-only, idempotent, non-destructive. Description adds return field details and default behavior (active only), which is valuable beyond annotations.

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

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

Two sentences, no fluff. Purpose, return fields, and usage advice all included efficiently.

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

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

Complete for a simple list tool: purpose, return values, usage guidance. No output schema needed; all relevant info provided.

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

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

Schema covers parameter with description (include_inactive). Description mentions 'active' default, relating to param. Schema coverage 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?

Description clearly states 'List the caller's active subscriptions' and enumerates returned fields (id, type, etc.). Distinguishes from siblings like subscribe/unsubscribe by explicitly focusing on listing.

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

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

Provides explicit use cases: 'review what you're monitoring before adding more' and 'find an id to cancel.' No explicit when-not, but 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 non-readonly/non-destructive, and the description adds meaningful behavior: rate-limited to 5 per identifier per day, free/no quota impact, daily digest review, and the claim_token round-trip mechanism for checking resolution status. This goes beyond the annotations. Slight gap is not specifying any other side effects of submitting feedback, but none are likely.

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 not bloated; every sentence carries operational guidance (when, what, exclusions, token mechanics, SLA, rate limits, cost). It is front-loaded with purpose and reads logically. It loses one point only because it could be trimmed slightly without losing critical info, but it remains easy to parse.

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 (categories, exclusions, token flow, rate limits, cost), the description covers all of it. There is no output schema, but the description explains what the return value will be: a claim_token on filing, or status on later lookup. This is complete for an agent to invoke and follow up 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 descriptions already cover all four parameters, giving a baseline of 3. The description adds extra useful semantics by explaining how to use claim_token in a follow-up call ('pipeworx_feedback({claim_token:"pwfb_…"})') and by telling users to describe issues in terms of Pipeworx tools/packs rather than pasting prompts, which enriches the 'message' and 'context' parameters.

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

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

The description opens with a specific verb and resource ('Tell the Pipeworx team something is broken, missing, or needs to exist'), making it unmistakably a feedback submission tool. It further distinguishes itself from all sibling tools by being the only one that communicates feedback to the Pipeworx team, and it even clarifies scope by excluding other MCP servers.

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 use cases are enumerated ('Use when a tool returns wrong/stale data... feature/data_gap... praise'). It also provides a clear exclusion and alternative: if the tool is not from this Pipeworx connection, file it with that server instead. This is about as clear as usage guidance gets.

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 valuable context: data source ('CF analytics-engine'), privacy ('no PII'), caching ('5min-1h depending on window'), and self-aggregating nature. 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 concise at about 4 sentences. It front-loads the core purpose and then provides structured bullet-style use cases. However, it could be slightly tighter by removing the introductory colon and bullet markers.

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 a simple tool with one optional parameter and no output schema, the description fully covers what the tool does, what it returns, and how it behaves (caching, data source). No gaps remain for an AI agent to understand invocation and expected results.

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 parameter that has a full enum description. The description goes further by explaining the semantics: shorter windows for 'hot right now' and longer windows for 'steady-state demand', which adds value beyond the schema's enum values.

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

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

The description starts with a clear verb phrase 'Returns' and specifies the exact outputs: top tools, top packs, and total call volume. It distinguishes the tool from siblings like ask_pipeworx or discover_tools by focusing on aggregate trending data derived from other agents' usage.

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

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

The description provides three explicit use cases (discovering hot data sources, confirming canonical tools, aligning use cases). It also notes caching behavior and gives guidance on window selection ('shorter windows surface what's hot right now; longer windows show steady-state demand'). It lacks explicit when-not-to-use, but the context is clear.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. Description adds extensive behavioral context: returns opportunities array, includes fill check logic, semantic anchor constraints (≥0.30 Jaccard similarity), partition filter (placeholders). 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 comprehensive but verbose. It front-loads the core purpose and then delves into details. While thorough, it 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 (arbitrage detection with multiple modes) and lack of output schema, the description is remarkably complete. It covers inputs, outputs, conditions, fill check, and edge cases, providing all necessary context.

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 both parameters described. Description adds extra meaning: explains slug format for event, seed question for topic, and details how each mode operates, enhancing understanding beyond the schema.

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

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

The description clearly states it finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) with specific examples, making the purpose very clear and distinct from siblings like polymarket_fill_risk.

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

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

Provides explicit guidance on when to use each argument: 'event recommended for a specific market', 'topic for cross-event scanning'. Also explains when not to trade (realizable_edge_pp <= 0) and refers to polymarket_fill_risk for custom sizing.

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

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

The description discloses detailed behavioral traits beyond the annotations: caching (1h), output structure (by_segment, diagnostics, fed candidates), filtering logic, and edge calculation (net of slippage, Kelly fractions). It explains why Fed bets are excluded. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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 structure, but it is quite lengthy due to detailed methodology. Every sentence adds value for such a complex tool, but it could be condensed without losing essential information. The caching note is at the end, which is acceptable.

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

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

The tool has 9 parameters, no output schema, and significant complexity. The description covers the output structure (segments, diagnostics, fed candidates), edge details, filtering knobs, and caching. It provides enough context for an agent to understand what the tool returns and how to use it 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?

All 9 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds context beyond the schema, e.g., explaining that min_partition_leg_kelly filters per-leg Kelly inside partitions, and that min_kelly does not filter partition arbs. This adds meaningful semantic 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 explicitly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It is built for a specific use case ('what should I bet on today') and distinguishes from siblings like polymarket_arbitrage and polymarket_edge_tracker by focusing on disagreement-driven opportunities rather than arbitrage or 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 provides clear context for when to use the tool ('discover opportunities without paging hundreds of markets') and explains the segments and knobs. However, it does not explicitly state when not to use it or compare it to alternatives like polymarket_arbitrage. The guidance is helpful but lacks exclusion criteria.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes beyond by explaining how snapshots are read, what the response format contains (tracked, expired, snapshot_dates), how decay and trend are computed, and the implications of snapshot gaps. No contradictions with annotations.

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

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

The description is front-loaded with the key purpose and insight, then efficiently details the response structure and limitations. Every sentence adds valuable information, and the length is appropriate for the complexity of the tool.

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 fully explains the return structure (tracked, expired, snapshot_dates) and the semantics of each field, including trend, decay, and lifespan. It also covers limitations like TTL and snapshot gaps, making it self-contained.

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

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

The schema has 100% description coverage for both parameters (days and window). The description merely restates the parameter names and defaults without adding new information or constraints 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 the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers a specific question about edge duration and trend, and implicitly distinguishes from the sibling 'polymarket_edges' by focusing on historical time-series rather than current snapshot.

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 when to use the tool: when you need to know how long an edge has existed and whether it is decaying. It provides context about data sources and limits but does not explicitly state when not to use it or contrast with alternatives like 'polymarket_edges'.

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

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

Annotations indicate readOnlyHint=true, which aligns with reading order book depth. The description adds behavioral context: it walks the ladder, returns verdict (clean/degraded/cannot_fill), and warns about thin books and forced directional risk. No contradiction with annotations; adds value beyond them.

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

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

The description is well-structured with sections for single-market and basket modes, using bold headers. It is somewhat lengthy but every sentence adds necessary detail. Slight verbosity in explaining edge cases, but overall efficient for the complexity.

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

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

Given the complexity of two modes and no output schema, the description comprehensively covers return fields, edge cases (thin legs, partial fills), and risk warnings. It lacks only some minor details like exact pagination but is sufficiently complete for an AI agent to understand behavior and usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant semantics: explains default side logic in basket mode (auto from partition sum), size interpretation (max spend vs target proceeds in single-market, settlement notional in basket), and required parameter relationship (one of market or event). This goes beyond schema but could be more concise.

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: checking realizable-vs-theoretical edge against live CLOB order-book depth. It explicitly distinguishes single-market and basket modes, lists return fields, and differentiates from siblings like 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?

The description provides explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains when not to use (partial fills convert arb into unhedged directional position) and alternatives are implied via sibling tool context.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description goes far beyond, detailing compatibility_warning conditions, temporal alignment, skipped cross types, and how leg-pair comparisons are dropped. 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 dense and front-loaded with purpose and modes. While verbose, every sentence adds value for understanding modes and safety fields. Minor redundancy (e.g., repeated warning about pre-mapped topics) but overall well-structured.

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

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

Despite no output schema, the description thoroughly explains response fields (leg-by-leg prices, spread array, safety fields) and edge cases. For a complex tool with two modes and multiple safety warnings, it is highly complete.

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

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

Schema coverage is 100% with clear descriptions for each parameter. The description adds context: pre-mapped list, examples, and explanation of when each parameter overrides the other. Extra context 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 states the tool calculates cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from sibling tools like 'polymarket_arbitrage' by focusing on cross-venue comparison with specific safety warnings.

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 modes (topic shortcuts vs explicit tickers) and provides guidance on safety fields like compatibility_warning and temporal_alignment. It warns most pre-mapped topics return compatibility_warning today. However, it doesn't explicitly state when NOT to use this tool vs alternatives like single-venue analysis tools.

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

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

Annotations already indicate read-only and idempotent; description adds scoping and pairing info 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?

Concise, well-structured description that front-loads the main purpose and then adds context.

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

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

Complete given the simple interface: covers all behaviors, scoping, and related tools.

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

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

Schema covers the key parameter fully; description adds behavior for omitted key (listing all), providing additional clarity.

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 retrieves a value by key or lists all keys, and distinguishes it from remember and forget 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?

Clearly states when to use (retrieve stored context) and scoping, but doesn't explicitly state when not to use.

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

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

Description states mark_read:true flags events as read, modifying persisted state, which contradicts annotation readOnlyHint=true. Similarly, idempotentHint=true is contradicted because mark_read changes subsequent results. The description itself is transparent, but the contradiction is severe.

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

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

The description is a single, well-organized paragraph of four sentences. It front-loads the purpose, then details parameters, behavior, and alternatives without 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?

Despite no output schema, the description explicitly lists return fields. With 5 optional parameters and 0 required, it explains all relevant behaviors (filtering, marking read, polling). References an alternative access method (GET registry endpoint) for completeness.

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

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

Schema coverage is 100% with descriptions. Description adds value by providing an example for type ('sec_8k'), clarifying since format (ISO timestamp), and explaining mark_read's effect on subsequent calls. This goes beyond schema, earning a 4.

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

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

The description clearly states the tool pulls fired events from a subscription feed, specifies return fields (source, citation_uri, raw payload), and highlights filter options. This distinguishes it from sibling tools like 'get_recent' and other disparate tools.

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

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

Provides guidance on polling ('Polls work fine'), filtering (type, since), and using mark_read for incremental reads. Mentions an alternative API endpoint for scripts/dashboards. Does not explicitly exclude sibling tools but gives practical usage context.

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

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

The description details fan-out sources (SEC EDGAR, GDELT→GNews fallback, USPTO), fallback logic, soft-fail behavior, and return structure, adding significant behavioral context beyond the read-only, idempotent 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 is front-loaded with purpose, uses effective examples and parentheticals, and contains no superfluous text.

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

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

Despite no output schema, the description explains the return format (grouped changes, total_changes, citation URIs) and covers edge cases (fallback, soft-fail), making it complete for effective tool use.

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

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

Although schema coverage is 100%, the description adds practical examples for 'since' (ISO date, relative shorthand, default recommendation) and clarifies 'value' (ticker or CIK), enhancing understanding 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 explicitly states it is a 'change feed for a company in the last N days/weeks/months' and provides example queries, clearly differentiating it from sibling tool 'entity_profile'.

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

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

It provides explicit example queries and includes a direct statement telling when to use 'entity_profile' instead, giving clear guidance on usage 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral details like scoping by identifier, persistence for authenticated users, and 24-hour retention for anonymous sessions, which 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?

The description is three concise sentences, front-loaded with purpose, and contains no superfluous information. Every sentence earns its place.

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

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

Given the tool's simplicity (2 params, no output schema), the description fully covers usage, persistence behavior, and pairing with siblings. Annotations provide additional safety hints, making it 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 input schema covers both parameters with descriptions, so the baseline is 3. The description adds context about storage across sessions but doesn't directly enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool 'Save data the agent will need to reuse later', specifying a verb and resource 'key-value pair'. It distinguishes itself from siblings by naming 'recall' and 'forget' as complementary 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 says 'Use when you discover something worth carrying forward' and provides alternatives: 'Pair with recall to retrieve later, forget to delete.'

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

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

Beyond annotations (readOnly, idempotent, openWorld), the description discloses important behavioral traits: identifier sources, explicit labeling with source, the `unresolved` field for unresolved identifiers, graceful degradation when GLEIF/OpenFIGI are unavailable, and that each call cascades through multiple endpoints. This adds substantial context beyond the annotation hints.

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

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

The description is longer than average but front-loaded with example queries and a clear directive ('Use FIRST'). It uses structured paragraphs for supported types and behavioral details. Every sentence adds information, though a more concise structure could improve scannability.

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

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

With no output schema, the description does a good job explaining return values for both company and drug types, including source labels and the `unresolved` field. It also explains fallback behavior when external sources fail. It does not provide a full output structure but is sufficient 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?

Schema coverage is 100%, with parameter descriptions already explaining accepted formats (ticker, CIK, name; brand/generic) and the type enum. The description adds examples and output context but does not materially enhance parameter semantics beyond what the schema already documents. 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 uses a specific verb 'resolve' and clearly states the resource: mapping user-spoken names to canonical/official identifiers required by other tools. It also lists supported entity types (company, drug) with specific identifier details, distinguishing it from sibling tools like entity_profile or compare_entities.

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

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

The description explicitly says 'Use FIRST whenever you have a name but need an ID,' providing clear when-to-use guidance. It also gives example user queries. However, it does not explicitly mention alternatives or when not to use, so it stops short of a 5.

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

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

Annotations provide readOnly, idempotent, openWorld, non-destructive hints. The description adds beyond that: it reveals that each entity is probed with ai_visibility_check, ranked by score, and output includes score, confidence, signal density—no contradictions.

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

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

Two sentences + a parenthetical example. Front-loaded with main action. Every sentence provides essential information without redundancy. Highly efficient.

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

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

Given no output schema, the description adequately covers input, behavior, and output structure (ranked list with metrics). It mentions optional shared context. Could mention max entity count (implied in schema) or error cases, but overall 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?

Schema description coverage is 100%. The description adds critical semantic detail: first entity is treated as 'subject' for narrative, rest as competitors. This goes beyond the schema's generic descriptions.

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

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

The description clearly states the tool's purpose: comparing AI visibility across multiple entities side-by-side, using ai_visibility_check, ranking, and surfacing most/least recognized. It distinguishes from siblings like ai_visibility_check (single entity) and covers a specific competitive audit 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?

The description gives explicit context: useful for competitive AI-marketing audits. It implies alternatives (e.g., use ai_visibility_check for single entity) but does not state when not to use this tool or list explicit exclusions. Clear enough for most agents.

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 critical behavioral details: bundlephobia's first measurement can take 5-30s, partial failures degrade gracefully, and sources_failed lists timeouts. No contradiction with annotations.

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

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

The description is information-dense but slightly long. It front-loads the main purpose and each sentence adds value. Minor trimming could improve conciseness, but it's 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 lists all return fields (summary block, per-advisory detail, links, alternative versions). Also covers partial failures and timing. Complete context 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?

Schema coverage is 100% with descriptions for both parameters. The description adds context: 'package' accepts scoped names, 'version' defaults to latest. This supplements the schema without being redundant, justifying a 4.

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

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

The description clearly states the tool is a composite check for npm packages, combining deps.dev and bundlephobia data. It distinguishes itself from siblings by specifying the exact data sources and use case ('should I add this npm package').

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

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

Explicitly says when to use: when an agent asks about safety, popularity, size, or cost. Also clarifies scope (NPM only in v1) and directs to deps.dev:version for other ecosystems. Mentions partial failure behavior, providing complete usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds return format ('matching developments with descriptions and sources') but no additional behavioral details like pagination or rate limits. 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?

Single sentence, front-loaded with action and scope, no fluff. Every word 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?

Description covers what, how, and what is returned. Annotations and output schema (exists) fill remaining gaps. Could mention the database source is dynamic (implied by openWorldHint), but complete enough.

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

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

Schema covers both parameters (query, limit) with descriptions. The description adds context about the search domain (new tools, APIs, etc.) beyond the schema, but the examples are also in schema. Minimal added value, but adequate.

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

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

The description explicitly states the verb 'Search' and the resource 'new tools, APIs, MCP servers, and frameworks' by keyword, distinguishing it from sibling tools like 'deep_research' or 'discover_tools' that have different scopes.

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 gives example queries but no explicit guidance on when to use this vs. alternative tools. With many sibling tools, context is implied but not stated.

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 embedding model (BGE-base-en), chunking (500-char overlapping windows), metric (cosine), character cap (200K) with truncation and flagging, and output details (passages with offsets and similarity scores). This goes well 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?

Concise and well-structured: front-loaded with the core functionality, followed by usage guidance, technical details, and limitations. Every sentence contributes.

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 (semantic search, chunking, offsets) and no output schema, the description thoroughly explains inputs, algorithm, behavior, return values, and integration with sibling tools. Fully adequate for correct agent invocation.

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

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

Schema coverage is 100% with good descriptions. The description adds value with example queries and clarifies the 'text' parameter as pre-fetched content, 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 performs semantic search inside a fetched record, with specific examples (SEC 10-K, article) and distinguishes from sibling ask_pipeworx_grounded by explaining the pairing strategy.

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 (record too big for prompt) and mentions the paired tool ask_pipeworx_grounded. No explicit when-not-to-use, but the context is clear.

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

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

The description adds significant behavioral context beyond annotations: OAuth requirement, idempotent creation (annotation says true), delivery channel behaviors, and limitations. 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 long but well-structured with front-loaded purpose and clear examples. Every sentence is informative, though some redundancy could be trimmed.

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 (nested objects, no output schema), the description covers return value, parameter details, prerequisites, channel behaviors, and limitations comprehensively.

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

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

With 100% schema coverage, the description still adds immense value by explaining each enum variant, parameter structure for each type, and delivery channel details. This goes far beyond the schema definitions.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription ID. It effectively 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?

The description explains when to use (set up monitoring), prerequisites (Pipeworx OAuth account), and limitations (sms cap, webhook auto-disable). It does not explicitly mention when not to use but provides enough context for appropriate 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 already set readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context: it returns dynamic example questions drawn from a live catalog, and it is safe to call. 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 front-loads the key purpose ('onboarding entry point') and is packed with useful information. Minor redundancy in listing the topics again, but overall efficient for its content density.

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 role as an onboarding entry point with a single optional parameter and no output schema, the description is fully complete: it explains what it returns, how to call it, and when to use it, including references to related meta-tools.

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

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

With 100% schema coverage, the schema already describes the optional topic parameter with enumerated values. The description adds value by showing usage examples ('finance', 'pharma') and explaining the behavior difference between providing a topic and omitting it.

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

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

The description clearly states that the tool returns category-bucketed example questions with exact tool+argument shapes, serving as the onboarding entry point. It differentiates itself from siblings like ask_pipeworx and discover_tools by specifying its role as a first-step discovery 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?

Explicitly instructs 'Use this FIRST when you do not yet know what Pipeworx can do'. Provides clear context for usage but does not explicitly state when not to use it or name alternatives beyond general sibling context.

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

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

Annotations (destructiveHint: false) are complemented by description: 'row is deactivated (not deleted)' and linkage to 'recent_alerts'. No contradiction, adds valuable behavioral context.

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

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

Two sentences, front-loaded with action, no redundant words. Every sentence adds necessary 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 1-param tool with no output schema, the description fully covers purpose, ownership constraint, and side effects. No gaps.

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

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

Schema covers id with description, but description adds 'returned by subscribe', providing origin context that enriches the schema's definition.

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 'Cancel a subscription by id' – specific verb and resource. Distinguishes from sibling tools 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?

Explicitly says 'Ownership is enforced — you can only cancel your own subscriptions', providing clear context for when to use. Could elaborate on alternatives but implication 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?

Annotations already indicate read-only, idempotent, non-destructive behavior, but the description adds rich detail: the structured SEC EDGAR/XBRL path vs. grounded pipeline, the six possible verdicts, and critical caveats like 'could_not_verify' meaning the check did not happen and carries a verification_error. This goes far beyond the annotation hints.

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 densely informative, with each section (examples, routing, return values, caveats) earning its place. It is front-loaded with trigger phrases and usage guidance. Slightly verbose but well-structured and not redundant.

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

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

Given no output schema, the description thoroughly explains return verdicts and their meanings, distinguishes between 'unsupported' and 'could_not_verify', and details the two processing paths. It also highlights efficiency by replacing multiple sequential calls. This is a complete description 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?

Schema coverage is 100%, so both parameters are already described. The description adds meaningful context: the claim parameter is illustrated with concrete examples, and tolerance_pct is clarified as an override for hallucination detection with a default derived from claim wording. This adds value beyond the schema's bare descriptions.

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

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

The description clearly states the tool's purpose: natural-language claim verification against authoritative sources. It provides explicit example triggers ("Is it true that…", "fact check", "verify the claim that…") and differentiates itself from siblings by noting it replaces 4–6 sequential calls, making it the dedicated fact-checking 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?

It gives explicit usage guidance: "Use whenever the agent needs to check whether something a user said is factually correct." It also provides routing rules for company-financial claims vs. other claims, and explains the tool consolidates multiple steps, making it clear when to invoke it over composing separate calls.

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 no destructiveness. The description adds the behavioral detail 'Returns the most relevant developments', which is helpful but minimal. No additional traits (e.g., pagination, freshness) are disclosed. Since annotations are rich, the description's contribution is modest but not contradictory.

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 sentence followed by two examples, front-loading the core action. Every sentence is necessary, and there is no filler. It is appropriately concise for the tool's simplicity.

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 2 parameters, rich annotations, and an output schema, the description covers the essential context: what the tool does, how to use it (via examples), and what it returns. It is complete for a straightforward NLQ tool, though additional context about result sorting or typical use cases could elevate it.

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 documents both parameters with descriptions (100% coverage). The description provides example values that illustrate natural language usage, adding some contextual meaning beyond the schema. However, it does not explain parameter semantics beyond what is in the schema.

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

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

The description states the verb 'ask' and the resource 'recent tools and developments', with concrete examples. This clearly defines the tool's purpose. However, it does not explicitly differentiate from similar siblings like 'search_developments' or 'get_ai_news', missing a chance to clarify distinction.

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

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

The description implies usage via examples ('any new MCP servers this week') but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. Given many sibling tools, a note on scope or preferred contexts would improve decision-making.

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