Arcgis Fairfax

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about the free default model, the need for an API key for Anthropic (with direct payment), and the return structure (per-model {score, confidence, signals, raw_response} + combined view). This adds value beyond annotations without contradiction.

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

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

The description is a single paragraph of four sentences, each serving a clear purpose: stating the action and output, explaining the models and key, describing the return format, and listing use cases. It is front-loaded with purpose, with no wasted words.

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

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

The tool has 4 parameters with full schema coverage, but no output schema. The description explicitly mentions the return shape (per-model {score, confidence, signals, raw_response} + combined view), explains the dual-model option, and gives usage context. This is complete for a probing 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%, so baseline is 3. The description adds meaning by explaining the default model (Workers AI Llama-3.3-70b), that the _apiKey is passed straight through to Anthropic, and that context helps disambiguate common names. This goes beyond the schema descriptions.

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

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

The description clearly states it probes LLMs for entity visibility and scores it (0-100) per model. It specifies the default model and optional Anthropic integration, and lists specific use cases like AI-marketing audits and brand checks. The verb 'Probe' and resource 'LLMs' are specific, though it doesn't explicitly distinguish from siblings like 'scan_competitor_ai_presence' 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?

The description provides clear context for when to use the tool (AI-marketing audits, pre-launch brand checks, competitive monitoring) and mentions that Anthropic requires a BYO key with direct payment. However, it does not explicitly tell when not to use it or mention alternatives among siblings.

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

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds valuable context: routes to 4774 tools, returns citation URIs, and works on every tier. 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?

Well-structured with key preference statement upfront, followed by scope, examples, and upgrade paths. Slightly long but every sentence earns its place.

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

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

Despite no output schema, description covers returns (structured answers with citation URIs), when to use, and examples. Complete for a tool with a single required parameter and no nested objects.

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

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

Schema coverage is 100% with descriptions for each alias. Description adds value with examples and clarifying that it accepts natural language queries, going beyond the schema's terse descriptions.

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

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

The description clearly states the tool routes factual questions to a vast array of verified sources, with specific examples. It distinguishes from siblings like ask_pipeworx_grounded and deep_research, and explicitly contrasts with web search.

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

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

Explicit guidance: 'PREFER OVER WEB SEARCH', 'START HERE', and detailed when-to-use alternatives. Provides concrete query patterns and examples.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: extra LLM call cost, explicit return format with refusal reasons, and data extraction process. 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 the core purpose and contains no filler. It is slightly verbose (two long sentences) but every part adds value. Could be split into bullet points for easier scanning, but overall efficient.

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

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

Given there is no output schema, the description thoroughly explains the return format (answer, evidence, confidence, source, fetched_at, refusal_reason) and possible refusal reasons. It also mentions the routing logic and cost, making it complete for high-stakes use.

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

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

Schema coverage is 100% (all 6 parameters have descriptions). The description merely mentions that the tool accepts aliases (query, q, prompt, etc.), which is already in the schema. It does not add new semantic meaning beyond what the schema 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 identifies the tool as a hallucination-resistant answer mode for high-stakes reads. It specifies the verb 'answer' and the resource 'Pipeworx data', and distinguishes it from the sibling 'ask_pipeworx' by emphasizing groundedness and refusal mechanisms.

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

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

The description explicitly states when to use this tool ('whenever an answer will be quoted, cited, or acted on') and when to avoid it ('prefer ask_pipeworx for casual lookups'). It also highlights the cost trade-off (one extra LLM call), providing clear decision 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 indicate read-only and idempotent. Description goes far beyond by detailing resolution, classification, fan-out examples, response shapes (result.market, result.analysis, result.evidence), resolver contract, parent event extraction, news fallback, safety checks, wide spread handling, and cancellation rule parsing. 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 a single dense block, not concise. It covers many details but could be better structured with sections or bullet points. The first sentence front-loads purpose, but the length may reduce readability for quick scanning.

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?

Extremely comprehensive given the tool's complexity. Covers all major aspects: input types, classification, fan-out examples, response shape details, resolver confidence, parent events, news handling, safety, closed markets, wide spreads, and cancellation rules. Without output schema, it fully describes the response structure.

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

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

Schema coverage is 100% with descriptions. The description adds value by explaining the 'depth' enum values (quick vs. thorough), providing example inputs, and contextualizing 'include_raw'. This enriches understanding beyond the schema alone.

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

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

Clearly states the tool's purpose: researching Polymarket bets by pulling Pipeworx data. The verb 'research' and resource 'Polymarket bet' are specific. While not explicitly distinguishing from siblings, the unique functionality (resolving market, classification, fan-out) is evident.

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 ('should I bet on X', 'what does the data say about Y', 'is there edge in Z'). Does not explicitly contrast with sibling tools, but gives context for when to use. Includes blocking conditions (low confidence, closed markets) which guide usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds specific behavioral details: data sources (SEC EDGAR, FAERS), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. 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 lengthy but well-structured, front-loaded with example queries, and every sentence provides useful information. Could be slightly more concise, but overall efficient.

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

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

With no output schema, the description compensates by noting 'returns paired data + pipeworx:// citation URIs per entity'. It describes data sources and sorting. Could be more explicit about the structure of the returned data, but sufficient for an AI agent to understand the behavior.

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 by explaining what each type returns (company: financial metrics; drug: count data), and what values mean (tickers/CIKs for company, names for drug). It also specifies min/max items for values array.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 companies or drugs, listing specific data points (revenue, net income, etc. for companies; adverse events, approvals, trials for drugs). It distinguishes from siblings like entity_profile by focusing on multi-entity comparison.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups' and gives example query patterns, but does not explicitly state when not to use the tool. However, the context is clear for comparative queries.

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

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

Annotations already provide readOnlyHint, openWorldHint, etc. The description adds execution time (15-60s), parallel decomposition, output format (findings packet with evidence, confidence, gaps[]), and limitation on non-structured topics. 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 thorough but slightly verbose. However, it front-loads critical information (account requirement, alternatives) and each sentence adds value. Could be tightened but remains effective.

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

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

Given the tool complexity (2 params, no output schema, 100% schema coverage, good annotations), the description covers prerequisites, output format, limitations, and alternatives comprehensively. It leaves no significant gaps for an agent to understand 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%. The description adds context for depth (explains enum values and defaults) and question (natural language, broad/multi-part fine). This goes beyond the schema's minimal descriptions.

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

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

The description clearly states it performs grounded multi-source research, decomposes questions into facets, and returns structured findings. It distinguishes from sibling tools like ask_pipeworx by specifying it's for broad/multi-part questions over structured data, not single lookups or breaking news.

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

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

Explicitly states when to use (broad/multi-part structured questions) and when not (single lookup, breaking news, colloquial topics), providing alternatives like ask_pipeworx. Also mentions account requirement and that 'thorough' depth needs a paid plan.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral detail: results are 'ready to call directly, no second schema lookup needed' and include 'full input schemas (with curated examples).' This complements annotations without contradiction.

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

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

The description is front-loaded with the purpose and usage context, followed by examples of inputs. It is efficient, though enumerating many domains adds length. Each sentence serves a purpose, but some trimming could improve conciseness.

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

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

Given the parameter count (6), no output schema, and no nested objects, the description adequately covers what the tool does, its output (top-N tools with schemas), and usage context. It does not explain return formatting in detail, but the description of 'names, descriptions, and full input schemas' is sufficient for an agent.

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

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description mentions aliases for 'query' but does not significantly augment the schema's information. Given high coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists numerous example domains (SEC filings, FDA drugs, etc.), making the scope unmistakable. This distinguishes it from sibling tools like 'deep_research' or 'search_datasets' which are about data discovery, not tool discovery.

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

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

Explicitly advises to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear context for when to use the tool versus alternatives, including the implication that it's for exploration before diving into specific 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 declare readOnlyHint and idempotentHint. The description adds behavioral details: fans out across multiple sources, includes a sunset date for USPTO PatentsView (soft-fails), and specific return fields. No contradictions.

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

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

The description is relatively long but well-structured with examples, preference note, and details of returns. Every sentence adds value, though minor 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?

Despite no output schema, the description thoroughly lists what is returned: cik, company_name, recent_filings with URIs, fundamentals, patents, news, LEI. It covers all necessary 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%, baseline 3. The description adds context: type is only 'company' for now, value can be ticker or CIK, and names not supported. Notes future support for person/place.

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: 'full cross-source profile of a US public company in ONE parallel call.' It provides multiple example queries and specifies the data sources and return fields, distinguishing it from siblings like resolve_entity.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and instructs to use resolve_entity for names, providing clear when-to-use 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 declare destructiveHint=true and readOnlyHint=false, so the description's behavioral disclosure is minimal beyond stating 'Delete'. It adds context about the purpose of deletion (stale/sensitive data) but does not elaborate on side effects or authorization needs.

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

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

The description is extremely concise: two sentences covering purpose, usage guidelines, and sibling context. Every sentence adds value, and the most important information ('Delete a previously stored memory by key') is front-loaded.

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

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

Given the tool's simplicity (one required parameter, clear destructive action, no output schema), the description is fully adequate. It provides all necessary context for an agent to decide when and how to use 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 has 100% description coverage for the single required parameter 'key'. The description adds no additional meaning beyond what the schema already provides (e.g., 'by key' mirrors the parameter definition). 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 uses a specific verb ('Delete') and resource ('memory by key'), clearly stating the tool's function. It distinguishes from sibling tools 'remember' and 'recall' by pairing them, implying complementary roles.

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 scenarios are provided: when context is stale, task is done, or to clear sensitive data. It also mentions pairing with 'remember' and 'recall', giving context for alternatives. No explicit when-not-to-use is stated, which would make it 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?

The description details the process: fetches the page, extracts title/description/key links, and emits standard markdown. This adds behavioral context beyond the annotations (readOnlyHint, idempotentHint) without contradiction.

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

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

The description is a single paragraph with three well-structured sentences: purpose, process, and use cases. No wasted words, front-loaded with key information.

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

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

Given the tool's simplicity (2 params, no output schema), the description fully covers what the tool does, its output format, and deployment location, 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%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only restating defaults for max_links and the URL's purpose.

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 generates a llms.txt file for any URL, specifying the exact output format and target use for AI crawlers. It distinguishes itself from sibling tools like ai_visibility_check by focusing on file generation rather than visibility checking.

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?

Usage scenarios are explicitly given: getting a client's site indexed, drafting for own project, or auditing competitor. It implies when to use over alternatives like ai_visibility_check, though it does not explicitly state when not to use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context on return values but does not disclose additional behavioral traits such as authentication requirements or rate limits.

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-structured sentence that efficiently conveys the purpose and output. Every word earns its place with no redundancy.

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

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

Although there is no output schema, the description adequately explains what the tool returns. It covers key aspects but could mention the format (e.g., JSON) or error behavior 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?

The sole parameter 'url' has 100% schema description coverage. The description mentions 'by url' but adds no extra meaning beyond the schema's description. 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 verb 'Get' and the resource 'ArcGIS Feature/Map Service layer's schema', enumerating what is returned: fields (name + type), geometry type, total record count, and capabilities. This distinguishes it from sibling tool 'query_layer' which retrieves data.

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 (to obtain schema) but does not explicitly state when not to use it or provide alternatives. While the context suggests it is for schema retrieval rather than data querying, explicit guidance would strengthen 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 declare readOnlyHint and destructiveHint; description adds default behavior (active only) and return fields, complementing them 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?

Two sentences, no fluff, front-loaded purpose, then returns, then usage.

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

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

For a simple list tool with one optional boolean parameter and no output schema, the description covers purpose, usage, parameter, and return fields completely.

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

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

Schema covers parameter with full description (include_inactive with default false); description doesn't need to add more, baseline 3.

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

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

Explicitly states 'list the caller's active subscriptions' and lists return fields, clearly distinguishing from sibling tools like subscribe and unsubscribe.

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

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

Provides clear when-to-use guidance: 'review what you're monitoring before adding more or to find an id to cancel.'

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 limited hints (readOnlyHint=false, etc.), but the description adds valuable behavioral context: rate-limited to 5 per identifier per day, free, doesn't count against quota, team reads daily, and signal affects roadmap. These are critical for an LLM to decide when and how to use the tool.

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

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

The description is concise (three sentences) and front-loaded with the core action followed by usage guidance and constraints. Every sentence adds necessary information without redundancy.

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

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

Given the tool's simplicity and lack of output schema, the description covers all essential aspects: purpose, when to use, what to include/exclude, rate limits, and impact. No gaps remain for an LLM to understand proper 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% and already explains parameters well. The description adds value by further clarifying the 'type' enum ('bug = something broke...') and instructs to be specific about tool names and errors. It also warns against pasting end-user prompts, going beyond schema.

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

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

The description clearly states the tool's purpose: sending feedback about bugs, missing features, data gaps, or praise. It distinguishes itself from any sibling tool, as none others serve a feedback function. The verb 'Tell' and the specific categories make it highly actionable.

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

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

Explicitly states when to use for bug, feature request, data_gap, praise, or other. Also advises what not to include (don't paste end-user prompt). However, it does not explicitly mention when NOT to use this tool in favor of alternatives, though given the tool's uniqueness, this is a minor omission.

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

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

Description adds data source, privacy, and caching details beyond annotations (readOnly, idempotent). No contradictions; fully explains behavior.

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

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

Three sentences plus bullet points. Front-loaded with core function then usage. Every sentence adds value, no redundancy.

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

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

No output schema needed; description comprehensively lists returned data (top tools, packs, total call volume). Annotations cover behavior gaps. Complete for this simple tool.

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

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

Single parameter 'window' is fully described in schema. Description adds semantic insight: shorter window for hot, longer for steady-state demand, enriching parameter meaning.

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

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

Description clearly states tool returns trending data: top tools, packs, call volume over windows. Uses specific verb 'Returns' and distinguishes from siblings by focusing on aggregated agent call signals.

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

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

Three explicit use cases (discovering hot data, confirming canonical choice, aligning use case). Implies windows for different needs. Could explicitly mention not to use for raw searches, but sibling context covers this.

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 show readOnlyHint true, and the description adds extensive behavioral details: monotonicity checks, partition sum, semantic anchor (Jaccard), partition filter (placeholders), and fill check with CLOB depth. 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?

Well-structured with front-loaded summary and logical sections, but slightly verbose with detailed internal logic. All sentences are necessary, but could be tightened.

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

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

No output schema, but description explains response format (opportunities array, partition_check object) and fill check behavior. Covers inputs, processing, outputs, and edge cases comprehensively.

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

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

Schema coverage is 100% but description adds substantial context: explains event/topic parameters with examples, internal logic, and what each mode does. Greatly enhances meaning beyond schema.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, and distinguishes two modes (event/topic) with specific use cases. It differentiates from sibling tools 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?

Explicitly specifies when to use each parameter: no args for trending scan, event for single-market, topic for cross-event. Also warns when not to trade (fill check returns negative edge) and directs 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 is highly transparent about internal algorithms, including model families, edge calculations (edge_pp_net after slippage, kelly_fraction), and filter logic. It explains why Fed bets are excluded (unreliable signal without paid data). It also mentions caching behavior ('Cached 1h at the KV level'). This goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) which only indicate safety and idempotency.

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: purpose, segment details, response fields, knobs, and diagnostics. Every sentence adds necessary information given the tool's complexity. However, it could be slightly more concise by grouping some details, though no information is 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 the tool's complexity (9 optional parameters, 3 segments, detailed edge calculations, no output schema), the description is remarkably complete. It explains the top-level response structure (by_segment, fed_candidates, _diagnostics), how to interpret edge metrics, and diagnostics for empty segments. Missing information like return value types is compensated by the detailed prose. The description leaves no critical gaps 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?

The input schema covers all 9 parameters with descriptions, but the tool description adds significant value: it explains how each parameter affects edge filtering (e.g., min_kelly skips small opportunities, min_partition_leg_kelly applies to per-leg Kelly inside partition arbs where min_kelly does not apply). It also provides rationale and recommendations (e.g., 'Polymarket has zero trading fees... but bid/ask + thin depth typically eats 20-50bp per trade'). This semantic enrichment is substantial.

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 and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It immediately states the use case ('what should I bet on today') and distinguishes itself from siblings by focusing on edge detection across multiple model families, unlike sibling tools like polymarket_arbitrage or polymarket_edge_tracker which likely target specific 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 explains when to use the tool: for discovering opportunities without paging hundreds of markets. It details the three segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) and when each applies (e.g., concentrated_longshot is 'rare-by-design'). It also explains tradeable-edge knobs and their effects. However, it does not explicitly state when to use this tool over its siblings, such as polymarket_edge_tracker or polymarket_arbitrage.

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

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

The description discloses key behaviors: that data comes from daily snapshots with TTL, decay computed from daily closes, snapshots written on cache-miss, and gaps in snapshot_dates indicate no scan. These details go beyond annotations and provide rich 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?

The description is somewhat long but well-structured: it starts with the core purpose, defines args, describes response fields, and ends with limitations. Every sentence is informative, though minor trimming could improve conciseness.

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

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

Without an output schema, the description fully explains the return structure: tracked[], expired[], snapshot_dates[] with their fields and limitations (TTL, decay calculation). This provides complete context for an agent to use the tool effectively.

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

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

Input schema has 100% coverage of both parameters with descriptions. The description adds default values, a max bound for days, and explicit example values for window (24hr, 1wk, 1mo), enhancing meaning beyond the schema.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' and answers a specific question: how long has an edge existed and is it shrinking? It distinguishes from raw edge data by contrasting fresh vs old edges, making the purpose specific and actionable.

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 historical decay analysis but does not explicitly contrast with sibling tools like polymarket_edges. It provides clear context on what the tool does, enabling inference of appropriate use cases, but lacks explicit 'when to use' versus 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?

Description adds substantial behavioral context beyond annotations. It explains the tool walks the order book ladder, returns fields like top_of_book, vwap_fill_price, slippage_pp, and warns about forced directional risk. Annotations (readOnlyHint, idempotentHint, openWorldHint) are consistent with the description, and the description enriches understanding.

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 clear sections for single-market and basket modes, using capitalization for emphasis. It is slightly long but front-loaded with the main purpose. Each sentence adds value, though 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 (two modes, multiple return fields, edge cases), the description is thorough. It explains the use case, modes, parameters, key outputs, and important warnings about thin books and forced directional risk. It is complete for an agent to understand when and how to use the tool.

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

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

Schema description coverage is 100% (baseline 3). The description adds meaning beyond schema: it explains the context of size_usd for single-market vs basket, default behavior for side in basket mode, and mentions clamping. This extra context justifies a score of 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's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes two modes (single-market and basket) and specifies use cases that differentiate it from sibling tools 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?

Explicit when-to-use guidance is provided: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains why theoretical overround on thin books is not capturable and warns about partial basket fills converting arb into unhedged directional positions.

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

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

Adds substantial behavioral detail beyond annotations (readOnlyHint, etc.): two modes, safety fields (compatibility_warning, temporal_alignment, skipped counters), and explains conditions under which spreads are meaningless. 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?

Description is verbose (~200 words) but well-structured with sections for modes, response, and safety fields. While every sentence adds value, could be more concise; however, complexity justifies length.

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

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

Comprehensive coverage for a complex tool with 3 optional params and no output schema. Explains response structure (leg-by-leg prices, spreads, compatibility_warning conditions, temporal_alignment) and edge cases, fully compensating for missing output schema.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning: explains topic parameter with list of shortcuts, shows overriding behavior of explicit tickers, and provides examples. Enhances understanding beyond schema descriptions.

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

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

Description clearly states the tool finds 'Cross-venue spread between Kalshi and Polymarket for the same resolving question'. It distinguishes itself from sibling tools (e.g., polymarket_arbitrage is intra-venue) by specifying cross-venue focus.

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

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

Provides explicit when-to-use guidance: two modes (topic shortcuts or explicit pairing), explains when compatibility warnings fire (non-equivalent bet shapes, unrelated events), and warns that real spreads are rarer than shortcuts suggest. No mention of alternatives, 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 declare readOnlyHint, idempotentHint, etc. Description adds context about returning attribute rows and geometry, and explains pagination parameters, complementing annotations 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?

Three short, clear sentences. Front-loaded with main purpose, followed by parameter explanation and usage example. No unnecessary words, but could be slightly more concise by merging sentences.

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

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

Covers purpose, parameters, example usage, and mentions output (attributes and geometry). Lacks details on response structure (e.g., features array) which output schema would provide, but sufficient for a query tool.

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

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

Schema coverage is 100%. Description adds value by describing SQL-like where, comma-separated out_fields, and providing a concrete example (where="1=1" + out_fields="*"), enhancing understanding beyond schema descriptions.

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

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

Clearly states 'Query an ArcGIS Feature Service / Map Service layer' with specific parameters. Distinguishes from sibling 'search_datasets' by mentioning 'from search_datasets' and focusing on querying a known layer URL.

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 directs to get the URL from search_datasets, and provides example usage ('where="1=1" + out_fields="*" to sample'). Does not specify when not to use, 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: it explains scoping ('Scoped to your identifier'), lists the two usage modes, and describes how it pairs with sibling tools. 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 concise (three sentences) and well-structured. It front-loads the core purpose, provides usage guidance, and includes relevant context about scoping and sibling tools. Every sentence contributes meaningful information without redundancy.

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

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

For a simple retrieval tool with no output schema, the description is complete. It covers both usage modes, explains scoping, gives examples, and mentions related tools. No additional context seems necessary for an agent to use the tool correctly.

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

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

The input schema has 100% coverage for its single optional parameter, with a description: 'Memory key to retrieve (omit to list all keys)'. The description adds value by elaborating on the behavior when the parameter is omitted, providing examples, and explaining the listing mode. This goes beyond the schema's basic description.

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

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

The description clearly states the tool's purpose: 'Retrieve a value previously saved via remember, or list all saved keys'. It uses specific verbs (retrieve/list) and identifies the resource (saved values/keys). It also implicitly distinguishes from sibling tools like forget and remember by describing its complementary role.

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 guidance on when to use the tool: 'Use to look up context the agent stored earlier'. It explains the two modes (with key to retrieve, without to list all) and gives concrete examples. While it does not explicitly state when not to use it, the context makes it clear that it is for retrieval only, and the mention of pairing with remember and forget implies alternatives.

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

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

Discloses that events carry source, citation_uri, and raw payload. Explains the mark_read side effect (flags events as read, so subsequent calls show newer ones). Notes that polling works. No contradiction with annotations (readOnlyHint, idempotentHint, openWorldHint are consistent).

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

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

Four sentences with no filler. Each sentence serves a distinct purpose: stating purpose, describing return fields, explaining filtering and mark_read, and mentioning polling and alternative access.

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 5 optional parameters, no output schema, and comprehensive annotations, the description covers return format, filtering, state mutation (mark_read), and alternative access. No obvious gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by giving an example type ('sec_8k') and explaining the effect of mark_read, which goes beyond the schema descriptions.

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

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

Clearly states the tool pulls fired events from the subscription feed. Specifies the resource (alerts) and mentions return fields (source, citation_uri, payload). Differentiates from siblings like 'recent_changes' and 'list_subscriptions' by focusing on alerts.

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 filtering by type and since, and explains the mark_read parameter. Mentions polling is fine and points to an alternative access method (direct URL). Does not explicitly state when not to use or list alternatives, but context is clear for typical usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds significant context: fan-out behavior, fallback mechanism, date parsing, soft-fail for USPTO. No contradiction; annotations and description align.

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

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

Single paragraph but well-structured, front-loaded with examples. Every sentence adds value. Could be slightly more scannable with bullet points, but still concise for the information 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?

Despite no output schema, description explains return structure (changes grouped by source, total_changes count, citation URIs). Covers error handling, fallbacks, and date parsing. Complete given tool complexity.

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

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

Schema coverage is 100%. Description adds valuable context beyond schema: clarifies 'since' format with examples ('7d', '30d', '3m', '1y', ISO date), suggests default '30d', and explains 'value' as ticker or CIK.

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

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

The description clearly states the tool provides a change feed for companies, with multiple sources (SEC EDGAR, GDELT/GNews, USPTO). Example queries like 'What's new with X' make it concrete. It explicitly distinguishes from sibling 'entity_profile' for static profiles.

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

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

Provides explicit when-to-use guidance with example phrasings, explains fallback behavior (GDELT to GNews), and recommends alternative tool 'entity_profile' for static queries. Covers edge cases like USPTO soft-fail and date format options.

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

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

Annotations provide idempotentHint=true, but description adds value: scoped by identifier, persistent vs 24-hour retention for anonymous sessions. No contradictions. Could mention idempotency effect on overwrites, but 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?

Concise yet informative, front-loaded with purpose and usage. A few extra words but earns its place. Could be slightly tighter.

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

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

Given no output schema and simple key-value params, description covers behavior, scoping, and lifetime. Pairs with recall/forget for completeness. Adequate for the tool's simplicity.

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

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

Schema covers 100% with clear descriptions (key examples, value as text). Description adds no new param info, but baseline 3 is appropriate as schema does the work.

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

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

The description clearly states the tool saves data for reuse across conversations/sessions, with specific examples like 'resolved ticker', 'target address'. It distinguishes from siblings recall and forget, which are explicitly named.

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

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

Provides explicit guidance on when to use ('when you discover something worth carrying forward') and pairs with recall/forget for retrieval/deletion, making alternatives clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by stating that each call 'cascades through several lookup endpoints internally', which helps the agent understand the underlying complexity and that it is a composite operation.

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

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

The description is somewhat lengthy but front-loaded with examples and key guidance. Every sentence adds value, though a minor trim could improve conciseness 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 has only 2 parameters, 100% schema coverage, and read-only annotations, the description provides complete context: explains return values (e.g., citation URIs), supported entity types, and internal behavior. No output schema exists, but the description adequately covers what the tool returns.

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 covers 100% of parameters, but the description adds significant meaning: for the 'type' parameter, it explains what each entity returns (ticker, CIK, company name, RxCUI, ingredient, brand) and for 'value', it specifies valid input formats (ticker, CIK, name, brand, generic name) and that company inputs are auto-disambiguated.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, listing supported types (company, drug) and providing concrete examples like 'What's the ticker for...'. It effectively differentiates from sibling tools by specifying it should be used first when a name needs an ID.

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 direct guidance on when to invoke. It also explains that each call replaces 2-3 manual lookups, reinforcing its role as a primary tool for identifier retrieval.

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, etc.), description adds that it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, signal density. No contradiction.

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

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

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

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

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

Despite no output schema, description explains return values. Parameters are fully described in schema. Sibling tools are listed, and use case is well-contextualized. Adequate for a read-only comparison tool.

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

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

Schema coverage is 100%, so baseline 3. Description adds context for 'context' parameter (shared, disambiguates) and 'entities' (first is subject). Does not detail 'models' or '_apiKey' beyond schema, which is already sufficient.

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 'Compare AI visibility across multiple entities side-by-side', specifies the action (compares), resource (AI visibility), and distinguishes from sibling tool 'ai_visibility_check' by indicating it aggregates multiple checks and ranks 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?

Explicitly states usefulness for competitive AI-marketing audits and gives an example. Implicitly contrasts with single-entity check via 'ai_visibility_check'. Lacks explicit 'when not to use' but context is clear enough.

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

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

Annotations already mark it as read-only, idempotent, non-destructive. The description adds valuable behavioral details: partial failures degrade gracefully with a 5-30s first measurement latency for bundlephobia, and sources_failed listing. No contradiction.

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

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

Description is relatively long but every sentence adds value. It front-loads the main composite purpose, then details use cases, ecosystem scope, partial failure behavior, and return format. Could be slightly tighter but effective.

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

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

Despite no output schema, the description fully describes what the tool returns: a summary block with specific fields, per-advisory details, links, and alternative versions. For a composite tool, this is complete and leaves no ambiguity.

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

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

Schema coverage is 100%, baseline 3. The description adds useful extra semantics: scoped packages accepted, and default version behavior. This compensates beyond schema-only understanding.

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

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

The description clearly states the tool's purpose: a composite check for evaluating whether to add an npm package, covering license, advisories, version history, bundle size, etc. It distinguishes from siblings by being a one-call aggregation for npm ecosystem.

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

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

Explicitly says to use when an agent asks about safety, popularity, size, or cost of adding a package. Also clarifies that v1 is NPM only and suggests deps.dev:version for other ecosystems, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context by specifying returned fields and the next steps, confirming non-destructive behavior.

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

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

Two concise sentences that front-load the purpose and essential details, with no wasted words.

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

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

Given no output schema, the description lists returned fields and provides usage context. It covers the essential information for a search tool, though it could mention limit behavior explicitly.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description does not add new details beyond the schema, so it meets the baseline without enhancement.

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 searches Fairfax County GIS datasets by keyword and returns specific fields including a URL for further use. It distinguishes from sibling tools like query_layer and layer_info by focusing on search.

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 explains when to use (search by keyword) and provides a follow-up action (pass url to query_layer/layer_info). It implicitly distinguishes from related siblings but does not explicitly state when not to use.

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

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

Annotations (readOnlyHint, etc.) are fully supported. Description adds BGE-base-en embeddings, cosine similarity over 500-char overlapping windows, 200K char cap with truncation flagging. No contradiction.

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

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

Five well-structured sentences, each adding unique value: purpose, use case, pairing, technical details. Front-loaded with main purpose, no redundancy.

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

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

Despite no output schema, description specifies return values (top-N passages with offsets and similarity scores). Covers truncation behavior, embedding model, and windowing. No missing information.

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

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

Schema coverage is 100% with descriptions for all 3 parameters. Description enriches with examples (e.g., query examples) and technical details (window size, char limit), adding value beyond schema.

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

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

Description clearly states 'Semantic search INSIDE a fetched record' with specific verb, resource, and examples (SEC 10-K, article). Distinguishes from sibling ask_pipeworx_grounded, indicating complementary use.

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: 'Use when the record is too big to cram into the prompt' and pairs with ask_pipeworx_grounded for grounded answers. Provides clear context-saving benefit and offset feature.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), the description provides extensive behavioral details: creation is a write operation, subscriptions persist, delivery channels have specific limits (e.g., 10 SMS per day), webhook auto-disables after 10 consecutive failures, and phone verification is required. These details add significant value and align with the annotations.

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

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

The description is appropriately sized for the tool's complexity. The first sentence front-loads the core purpose and result. Subsequent sentences are well-structured: prerequisites first, then type examples, then delivery options. Every sentence adds value, and there is no redundancy or fluff.

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

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

Given the tool has three parameters (including nested objects), no output schema, and moderate complexity, the description is complete. It covers all necessary aspects: return value, authentication requirements, type-specific parameter examples, delivery channel constraints and capabilities, and failure behavior. No gaps are apparent.

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

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

The input schema has 100% coverage for parameters, but the description adds substantial meaning beyond the schema. For 'type', it enumerates all enum values with examples. For 'params', it provides type-specific structures (e.g., 'sec_8k' with ticker and items). For 'delivery', it explains channel behavior, constraints, and webhook HMAC verification. This greatly aids correct parameter usage.

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 'Create a proactive monitoring subscription to a live-data event stream' and specifies the return value ('Returns the new subscription id'). It uses a specific verb and resource, and lists supported types with examples. While it does not explicitly differentiate from sibling tools like 'list_subscriptions' or 'unsubscribe', the purpose is unambiguous.

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

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

The description mentions a prerequisite: 'Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions)'. However, it does not explicitly state when to use this tool versus alternatives like 'list_subscriptions' (to view existing subscriptions) or 'unsubscribe' (to remove one). The usage context is implied but lacks explicit guidance on 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?

Discloses that results are drawn from the live catalog of thousands of tools, that returns include exact tool+argument shapes, and describes behavior for optional topic parameter. Annotations already indicate read-only, idempotent, non-destructive; description adds substantial 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?

Well structured with common queries front-loaded. Every sentence adds value, but could be slightly more concise. Still, it's informative without being overly verbose.

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 schema, annotations, and no output schema, the description fully covers purpose, usage, parameters, and behavioral traits. No gaps remain for effective tool selection and 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?

Only one parameter (topic) with 100% schema coverage. Description explains its optional nature, lists possible values, and clarifies that omitting gives full spread. Adds meaning beyond the schema description.

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

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

The description clearly states the tool returns example questions categorized by topic, with exact tool+argument shapes. It distinguishes from siblings like ask_pipeworx and deep_research by positioning itself as an onboarding entry point.

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

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

Explicitly says to use it FIRST when you don't know what Pipeworx can do. Provides clear context for when to call with no arguments vs. with a topic. Could improve by explicitly listing when not to use it (e.g., if you already know what to ask).

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

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

Adds context beyond annotations: ownership enforcement (only own subscriptions), deactivation instead of deletion, and preservation of historical events. Annotations already indicate idempotent and non-destructive, but description enriches with concrete behavioral details.

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 filler. Front-loaded with action and resource, followed by important constraints. Every sentence adds value with no redundancy.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers key aspects: what it does, ownership, and lifecycle behavior. Could mention return value or error conditions, but not critical for such a simple tool.

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

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

Schema coverage is 100%, so baseline is 3. Description repeats schema info that id is a uuid from subscribe, adding no new semantic meaning beyond what the schema already provides. No additional parameter guidance.

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 action (Cancel), resource (subscription), and identifier (id). Distinguishes from sibling tools like subscribe and list_subscriptions by specifying ownership enforcement and deactivation behavior.

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

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

Implies usage context (own subscriptions only) and effect (deactivation, not deletion), but does not provide explicit when-to-use or alternatives. No exclusion criteria or conditions for not using this tool.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds value by specifying the data source (SEC EDGAR + XBRL), the verdict types, citation format, and efficiency claim, without contradicting annotations.

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

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

The description is somewhat verbose but well-organized with trigger phrases, scope, replacement claim, and output details. It earns its length by providing comprehensive guidance, though could be slightly more concise.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers domain, verdict types, source, and efficiency benefit, making it complete enough for an agent to understand without ambiguity.

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

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

With 100% schema description coverage, baseline is 3. The description provides natural language examples and clarifies the required input format, adding meaningful context beyond the schema's minimal description.

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

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

The description explicitly states the tool is for fact-checking natural-language claims, with specific trigger phrases ('Is it true that...', 'fact check'), and distinguishes itself from siblings by noting it replaces 4-6 sequential calls, clearly defining its unique 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?

Clear directive 'Use whenever the agent needs to check whether something a user said is factually correct' with example triggers, but does not specify when not to use (e.g., non-financial claims), though it's implied by the scope.

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