Data Brussels

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

Annotations already indicate read-only, open-world, and idempotent hints. The description adds valuable context: the default free model, cost implications for Anthropic (BYO key), and the return structure (per-model scores combined view). 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?

Four sentences, each earning its place: first sentence states the core purpose, second explains the default and paid options, third describes the output, fourth lists use cases. No filler.

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

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

Despite no output schema, the description adequately details the return format (per-model object with score, confidence, signals, raw_response). For a tool with 4 parameters and a straightforward output, this is sufficient.

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

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

With 100% schema description coverage, baseline is 3. The description adds examples (e.g., 'Pipeworx', 'B2B SaaS') and clarifies the _apiKey's purpose ('passed straight through'), which enhances understanding beyond the schema.

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

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

The description clearly defines the verb 'probe' and resource 'LLMs', specifies the scoring range (0-100), and differentiates from siblings by focusing on AI visibility auditing. No sibling tool has a similar 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?

The description provides explicit use cases (AI-marketing audits, pre-launch checks, competitive monitoring) and explains when to pass the _apiKey for Anthropic. However, it does not explicitly state 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description adds value by detailing how the tool routes to 5,008 sources, returns structured answers with citation URIs, and works on every tier in one fast call. No contradictions.

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

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

The description is long but well-organized with clear sections and front-loaded with the important directive to prefer over web search. Every sentence contributes useful information, 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?

Given the tool's complexity (many sources, multiple sibling tools, no output schema), the description thoroughly covers purpose, usage, examples, and when to use alternatives, making it fully complete for an agent to select and invoke correctly.

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

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

With 100% schema description coverage, baseline is 3. The description adds practical examples and clarifies that the single required parameter is a natural language question, accepting multiple aliases, thus enhancing usability 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 defines the tool as routing questions to verified sources and returning structured answers with citations. It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by specifying their different use cases.

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

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

The description explicitly states to prefer this tool over web search, provides extensive examples of when to use it (e.g., SEC filings, FDA data, news), and gives clear guidance on stepping up to alternatives (grounded, deep_research) for specific needs.

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 claims the tool is a router with the same 5,008 tools, some of which may be mutating, but annotations declare readOnlyHint=true. This is a direct contradiction: a router that can invoke mutating tools cannot be read-only. No clarification is provided.

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

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

The description is detailed and front-loaded with key points (beta status, source-preference). It could be slightly more concise but every sentence contributes value without redundancy.

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

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

Provides essential context for a beta tool: experimental routing, comparison with stable, and fallback behavior. Lacks explicit output schema description but references 'same response shape' as ask_pipeworx, which is reasonable given the tool's complexity.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description adds no additional meaning beyond stating it uses the same arguments as ask_pipeworx, which is not specific to parameters.

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

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

The description clearly states the tool is a beta version of ask_pipeworx, acting as a universal router with the same set of tools and arguments. It specifies the key difference: source-preference ranking. This distinguishes it from sibling tools like ask_pipeworx and ask_pipeworx_grounded.

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 using this tool when 'you want the newest routing' and notes that results are compared against the stable router. This provides clear when-to-use guidance and implies the alternative (ask_pipeworx) for stable behavior.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds that the tool extracts answer only from tool result, details return format (answer, evidence, confidence, source, etc.) and explicit refusal reasons (not_in_source, no_tool_match, etc.), going beyond annotations.

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

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

Description is relatively long but each sentence adds value. It is front-loaded with purpose and includes necessary details. Could be slightly more concise but effective.

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

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

Given the complexity (5,008 tools, 1318 sources) and no output schema, the description fully explains return format, refusal reasons, and use cases, making it complete for an AI agent to decide and use correctly.

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

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

Schema coverage is 100% with all parameters as aliases for question. Description adds that question is in natural language and lists aliases, providing useful context beyond the schema's 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?

Description clearly states the purpose: hallucination-resistant answer mode for high-stakes reads. It explains the mechanism (picks tool, fetches data, extracts answer) and differentiates from sibling ask_pipeworx by noting the grounded approach and extra cost.

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 (answers that will be quoted, cited, acted on, e.g., financial, legal, medical) and when not to (prefer ask_pipeworx for casual lookups). Provides clear 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 indicate read-only, idempotent, and non-destructive. The description adds extensive behavioral details: low-confidence short-circuits, closed market handling, illiquidity notes, resolution-rule risk, news fallback, and fan-out patterns. 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 very long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, etc.) and front-loaded with the main purpose. Every sentence adds value, but the length may strain token limits. Still, it is organized for easy 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?

Given the tool's complexity (multiple classifiers, fan-out paths, response shapes, edge cases), the description covers virtually all aspects: resolution matching, parent event extraction, news fallback, safety features, cancellation rules. Without an output schema, the description fully explains return values.

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

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

Schema coverage is 100%, and the description adds significant context: market parameter accepts slug, URL, or question text; depth parameter explains quick vs thorough; include_raw describes response size impact and use cases. Examples are provided.

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

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

The description clearly states the tool researches a Polymarket bet by pulling Pipeworx data, explains the process (resolves market, classifies, fan-out, returns evidence), and gives usage examples like 'should I bet on X'. It is distinct from siblings in its comprehensive research approach.

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

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

Explicitly tells when to use: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z". It also provides guidance on inspecting market_match_confidence and resolution risk, effectively guiding the agent's decision-making.

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, and destructiveHint. The description adds valuable behavioral details: for companies it pulls latest 10-K data from SEC EDGAR/XBRL with off-calendar handling, and for drugs it pulls FAERS/FDA/trial counts. Results sorted by primary metric. 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 somewhat long but each sentence adds value and it is front-loaded with natural language triggers. 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?

Given complexity (two types, multiple data sources, sorting), the description covers essential points including return of paired data and citation URIs. It could elaborate on sorting, but is sufficiently complete 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 coverage is 100%, so baseline 3. The description adds meaning by explaining the data sources for each type and giving examples (tickers, drug names). This goes beyond the schema's enum and array descriptions.

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

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

The description uses specific verbs like 'compare' and 'side-by-side comparison', identifies the resource (companies or drugs), and provides example natural language triggers. It explicitly distinguishes from sibling tools by recommending this over sequential single-pack lookups.

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

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

The description clearly states when to use (comparing entities) and what to prefer over (sequential lookups), and specifies the max items. It lacks explicit 'when not to use' but the provided context is sufficient.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context by detailing the return content (fields/schema, themes, record count). No contradiction. Lacks additional behavioral traits like permissions or limits, but given annotations, it's adequate.

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?

One sentence, highly concise, front-loaded with purpose. No wasted words.

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

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

For a simple single-parameter tool with no output schema, the description adequately explains return value and usage context. Could mention that dataset_id comes from search_datasets (already in schema), but overall complete.

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

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

Schema coverage is 100% with a description for dataset_id. Description adds no extra parameter meaning beyond the schema. Baseline 3 is appropriate.

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

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

Description clearly states the tool gets metadata for one Brussels Open Data dataset, specifying what metadata (fields/schema, themes, record count) and distinguishes from siblings like search_datasets and query by noting it should be called before querying.

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 to call before query to learn column names, indicating when to use. Does not include explicit when-not or alternatives, but context is sufficient given sibling differentiation.

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

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

Description adds context beyond annotations: expected latency (15-60s), gap reporting, contradiction scans, and that it never invents. No contradiction with annotations (readOnlyHint=true, etc.).

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

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

Very long description with multiple paragraphs. While front-loaded with critical info (account requirement, alternative), the verbosity may reduce readability. Could be more concise without losing key details.

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

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

Despite no output schema, the description thoroughly explains the return format (findings packet with evidence, confidence, source, citation, gaps, contradictions). Covers all necessary aspects 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?

Schema coverage is 100%, so baseline 3. The description adds significant detail on the depth parameter (quick=3, standard=5, thorough=8 with hops) and explains the question parameter's role. Slight redundancy with enum descriptions but adds value.

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

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

The description clearly states it performs grounded multi-source research across structured data, decomposes questions into facets, and routes them in parallel. It distinguishes itself from open-web search and sibling tools like ask_pipeworx.

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

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

Explicit guidance on when to use (broad/multi-part questions) and when not (single lookup or current news). Provides alternatives (ask_pipeworx) and prerequisites (account sign-up).

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which are consistent with the description. The description adds context about the return value (top-N tools with full schemas) and that results are 'ready to call directly', but does not contradict or add significant behavioral details beyond annotations.

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

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

The description is informative but somewhat lengthy due to listing many domains. However, it is front-loaded with the core purpose, and every sentence adds value. Could be slightly more concise but still effectively communicates.

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

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

Given no output schema, the description adequately explains what is returned (top-N tools with names, descriptions, schemas). All 6 parameters are documented in the schema, and the description covers the main required parameter. It is complete enough for an agent to use this 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining aliases for the query parameter and providing examples in the schema's examples field, which helps the agent understand how to formulate a query.

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: finding tools by describing data or task. It lists a wide range of domains (SEC filings, FDA drugs, etc.) and distinguishes this tool from siblings by focusing on discovery of available tools rather than performing a specific task.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set', providing clear guidance on when to use it. It also implies not to use when you already know the specific tool, which helps differentiate.

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 cross-source fan-out, patent sunset date and soft-fail, fundamentals sorting, news fallback, and that only company type is supported. No contradiction with annotations which are all safe/read-only.

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

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

Front-loaded with examples and core purpose. Some details like patent sunset could be streamlined, but overall well-structured and efficient for the complexity.

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

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

Despite no output schema, the description thoroughly details all return fields (filings, fundamentals, patents, news, LEI) and their structure. Limitations (patent sunset, name support) are acknowledged. Complete for a complex cross-source 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% and descriptions are already good. Description adds context for value parameter (ticker vs CIK, names not supported) and type enum restriction, going slightly beyond schema.

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

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

The description explicitly states it provides a 'full cross-source profile of a US public company in ONE parallel call' and lists return fields. It distinguishes from chaining individual lookups by saying 'ALWAYS PREFER' over alternatives. The examples clarify the specific use case.

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

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

Clear when to use: when user asks for holistic company info. Explicitly advises against using names and directs to resolve_entity first. States preferred over chaining single-pack calls.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds no new behavioral traits beyond stating the action; does not detail side effects or permissions.

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 focused sentences: first states action, second provides context. No redundant 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?

Tool is simple; description covers main purpose and usage. Could mention behavior when key is missing, but idempotency hint compensates.

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

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

Schema coverage is 100% and description adds no extra meaning beyond what is in schema for the single 'key' parameter.

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

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

Description clearly states the verb (Delete) and resource (previously stored memory by key). Differentiates from sister tools remember and recall by indicating deletion.

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

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

Explicitly states when to use: when context is stale, task done, or to clear sensitive data. Recommends pairing with remember and recall.

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, and non-destructive nature. The description adds behavioral details like fetching the page, extracting title/description/key links, and emitting standard markdown format. This complements annotations well 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 two sentences followed by a bullet list, all front-loaded with the core purpose. Every sentence serves a clear function, making it easy to parse without 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 is simple with two parameters and no output schema. The description adequately covers the returned format and use cases. It does not mention error handling or edge cases (e.g., unreachable URL), but those are minor for a read-only tool with idempotent 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%, so the baseline is 3. The description does not add significant new meaning beyond the schema's parameter descriptions (url as full URL, max_links with default and max). It explains what the tool does with the parameters but not their syntax or constraints.

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

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

The description clearly states the tool generates an llms.txt file for any URL, specifying the output format and use cases for AI crawlers. It distinguishes the tool from siblings like 'scan_competitor_ai_presence' by focusing on file generation.

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

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

The description explicitly lists three useful scenarios (client indexing, personal drafting, competitor auditing), giving clear context for when to use this tool. However, it does not mention when not to use it or provide explicit alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds that it returns 'active subscriptions' by default and specifies the returned fields, providing behavioral context beyond the annotations.

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

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

The description is two sentences: first stating functionality and output, second giving usage guidance. It is front-loaded and contains no unnecessary words, making it highly concise and structured.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers the essential aspects: what it lists, the returned fields, and when to use it. It does not mention pagination or limits, but these are likely unnecessary for the 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?

The only parameter, 'include_inactive', is fully documented in the schema with a description and default. The tool description does not add any additional meaning or usage hints for this parameter, so the schema does all 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 verb 'List' and the resource 'the caller's active subscriptions'. It also lists the returned fields (id, type, params, etc.), which distinguishes it from sibling tools like 'subscribe' and 'unsubscribe' that perform different actions.

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

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

The description explicitly advises when to use this tool: 'review what you're monitoring before adding more' (suggesting use before 'subscribe') and 'find an id to cancel' (suggesting use before 'unsubscribe'). This provides clear context, though it does not exhaustively state when not to use it.

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

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

Annotations are present but description goes beyond by stating rate limits (5 per day), that it's free and doesn't count against quota, and that team reads daily. 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?

Concise at ~80 words, front-loaded with purpose, every sentence adds value. Structured with clear use cases and constraints.

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 feedback tool with 3 params and no output schema, the description fully covers purpose, usage, constraints, and behavioral notes. No gaps.

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

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

Schema coverage is 100%, but description adds valuable guidance for the 'message' parameter: don't paste end-user prompt, describe in terms of Pipeworx tools/packs. Adds 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?

Clearly states the tool is for giving feedback (bug, feature, data_gap, praise) to the Pipeworx team. Distinguishes from siblings as no other sibling tool is for feedback.

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 lists when to use (bug, feature, data_gap, praise) and what not to do (don't paste end-user prompt). Also mentions rate limits and that it's free, providing clear context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: data is derived from CF analytics, no PII, cached 5min-1h. It does not contradict annotations.

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

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

The description is concise (about 100 words), well-structured with bullet points for use cases, and front-loads the core purpose. Every sentence adds value.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: purpose, use cases, parameter, data origin, caching, and privacy. It is fully complete.

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

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

Schema coverage is 100% for the only parameter, 'window'. The description adds meaning beyond the schema by explaining the semantic difference between shorter and longer windows ('hot right now' vs 'steady-state demand').

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

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

The description clearly states the tool returns top tools, top packs, and total call volume over a recent window. It uses specific verbs ('Returns') and distinguishes from siblings by focusing on trending/current activity ('What other AI agents are calling').

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

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

The description explicitly lists three use cases (discovering hot data sources, confirming canonical choice, seeing alignment) which provide clear context for when to use. However, it does not mention when not to use or suggest alternatives, so it's slightly below 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds extensive behavioral details: monotonicity logic, partition checks, semantic anchor, partition filter, fill check against CLOB depth, and caveats like skipped_low_similarity. 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 clear sections and front-loaded main purpose. However, slightly verbose with some redundant explanations (e.g., fill check details). Still, every sentence adds value, so it's concise for the complexity.

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

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

Despite no output schema, the description thoroughly explains the response structure (opportunities array, partition_check object) and fill check logic. Covers all usage modes and edge cases, making it complete for an arbitrage detection 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 descriptions cover 100% of parameters, but the description adds significant context, including examples of event slugs and topic seed questions, and differentiates when to use each parameter. This compensates fully beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, specifying the verb 'find' and resource 'arbitrage opportunities on Polymarket'. It distinguishes from sibling tools like polymarket_fill_risk by directing usage.

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

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

Explicitly explains when to use no args for trending scan, pass event for specific market, or topic for cross-event scan. Recommends event mode and provides conditions for not trading (e.g., realizable_edge_pp <= 0). 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?

Annotations show readOnly, openWorld, idempotent. Description adds extensive behavior: edge computation details (lognormal, GDELT, overround correction), Kelly fractions with caps, slippage subtraction, 24h-move warning, caching behavior ('cached 1h at KV level'), and filter skip diagnostics. Far exceeds annotation coverage.

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

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

The description is very long and dense. It uses clear segment labels and front-loads purpose, but includes excessive detail on model formulas that may not be necessary for selection. Could be more concise while retaining utility.

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

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

Despite no output schema, the description fully explains return structure (by_segment, fed_note, diagnostics) and all edge metrics. Covers caching, and why Fed bets are unreliable. For a complex tool with 9 parameters, it leaves minimal gaps.

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

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

Schema coverage is 100% (baseline 3). Description adds substantial context: min_kelly as half-Kelly fraction, min_edge_pp net of slippage, slippage_pp with market context, max_spread_pp and min_liquidity with example thresholds. This added meaning elevates the score above baseline.

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

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

The description clearly states the tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, and is built for 'what should I bet on today'. It distinguishes from siblings by detailing three model families and their specific methods.

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 usage context: 'scan top markets', 'discover opportunities without paging'. Provides detailed guidance on when to use tradeable-edge knobs (min_liquidity, max_spread_pp) and explains Fed bets exclusion. Tells agents how to interpret empty segments via diagnostics.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: response structure (tracked, expired, snapshot_dates), field meanings, decay computation, snapshot write triggers, and data gaps. This goes well beyond the annotations.

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

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

The description is relatively long but each sentence adds value. It is front-loaded with the core purpose, then details the response structure and limitations. Could be slightly more concise, but it is well-organized and informative.

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

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

Without an output schema, the description must explain return values. It thoroughly describes tracked[], expired[], and snapshot_dates[], including fields like trend, decay_pp_per_day, lifespan_days, and median lifespan. It also covers limitations (history depth, decay basis). This is highly complete for a complex tool.

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

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

Schema coverage is 100% with descriptions for both parameters. The description confirms defaults (days=14, window='1wk') and adds nuance (days max 30, window families) but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool provides edge persistence and decay telemetry from daily snapshots, answering 'how long has this edge existed and is it shrinking?' It distinguishes itself from siblings like polymarket_edges by focusing on historical persistence rather than current edges.

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

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

The description includes a LIMITS section with constraints like 60-day TTL and start time, and implies usage context (fresh vs. old edges). However, it does not explicitly list when to use this tool versus alternatives, though the differentiation from sibling tools 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 indicate safe read-only behavior. The description adds rich behavioral context: walks ladder, returns specific fields like top_of_book, slippage, verdict, and warns about thin legs and forced directional risk in basket mode. 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 detailed and well-structured with mode breakdowns, but slightly long with capitalized emphasis. Every sentence adds value, but could be slightly condensed 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, no output schema), the description is comprehensive. It lists all return fields for both modes, explains edge cases (thin legs, forced directional risk), and provides sufficient context for correct invocation.

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

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

Schema coverage is 100%, but the description adds value beyond: explains size_usd interpretation (max spend vs target proceeds), default and clamping (10–1,000,000 not in schema), and auto detection for side in basket mode. Clarifies semantics for both modes.

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

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

The description clearly states the tool's purpose: checking realizable-vs-theoretical edge against live order-book depth. It distinguishes between two modes (single-market and basket) and contrasts with 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?

Explicitly states when to use: before acting on polymarket_arbitrage signals or trades above ~$500. Also explains risks of partial fills converting arb into directional positions, providing clear guidance on when not to rely on theoretical edges.

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

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

Discloses safety fields (compatibility_warning, temporal_alignment, skipped counters) and explains their meaning. Annotations already mark it as read-only and idempotent; the description adds context on how the tool handles mismatched event structures and what data is returned. 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 fairly long but well-organized with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS). Every sentence conveys useful information, though some sentences are verbose. Overall, it's efficient for the complexity of the tool.

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

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

Despite no output schema, the description adequately describes the return fields (raw probabilities, top_spreads_pp, compatibility_warning, temporal_alignment, skipped counters). It covers edge cases (non-equivalent bet shapes, skipped legs) and temporal alignment implications. The description is complete for a complex cross-venue tool.

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

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

Schema coverage is 100% with descriptions for each parameter. The description explains the interplay between 'topic' and explicit overrides, lists the 10 pre-mapped topics, and provides example values for explicit parameters. This adds value beyond the schema by clarifying usage semantics.

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

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

Clearly states it computes cross-venue spread between Kalshi and Polymarket for the same resolving question. Distinguishes from siblings like polymarket_arbitrage which focus on single venue. Specific verb 'compute spread' with resource 'same resolving question across two venues'.

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 describes two modes (topic shortcuts vs explicit tickers) and when to use each. Warns that pre-mapped topics often return compatibility warnings, so they are not reliable for trading. Provides criteria for when spreads are meaningless (temporal misalignment, non-equivalent bet shapes).

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

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

The description adds value beyond annotations by specifying the use of ODSQL and listing supported SQL operations. Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior, and the description aligns with 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?

The description is two sentences, front-loaded with the primary action, and every sentence adds distinct information. No fluff or redundancy.

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

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

The description covers the core functionality and operations well. While it lacks mention of return format or error handling, the tool's simplicity and the presence of annotations mitigate the need for more detail. It reasonably equips an agent 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 coverage is 100% with well-described parameters. The description adds high-level context by mapping SQL clauses to parameters (where, select, group_by, order_by) and indicating override behavior (where overrides query), providing meaning beyond individual parameter 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 verb 'Query', resource 'records from a Brussels Open Data dataset', and specifies the query language 'ODSQL'. It enumerates supported operations (filter, aggregate, sort, paginate), distinguishing it from sibling tools like search_datasets which search for datasets, not records.

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 structured ODSQL queries but does not explicitly state when to use this tool versus alternatives (e.g., search_datasets for dataset discovery, search_within for free-text). No when-not-to-use guidance or explicit alternatives are provided.

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

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

Annotations already indicate read-only and idempotent. Description adds valuable context about scoping to identifier and listing keys on omission, 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?

Three sentences, each essential, front-loaded with action. 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?

Covers purpose, usage patterns (retrieve vs list), scope, and pairing with siblings. Sufficient despite no output schema.

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

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

Schema has 100% coverage with same description for key. Description adds no new parameter-level detail beyond schema, so baseline 3 applies.

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

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

Description specifies verb (retrieve/list) and resource (saved values/keys), clearly differentiating from siblings remember and forget.

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

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

Explicitly states when to use to look up stored context without re-deriving, and mentions scoping. Lacks explicit when-not-to-use or alternative tools beyond pairing.

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 states that mark_read:true flags events as read and affects future calls, implying a state change. However, the annotation declares readOnlyHint=true, which contradicts this. The description is accurate but contradicts the annotation.

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, front-loaded with the main purpose. It covers essential points without verbosity, making it efficient and easy to scan.

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 5 parameters, no output schema, and strong annotations, the description explains the return structure (source, citation_uri, raw payload) and behavior (mark_read, polling). It is complete enough for most use cases, though it does not detail pagination or limit behavior beyond 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?

The description adds significant value beyond the 100% schema coverage by providing example values (e.g., 'sec_8k' for type) and explaining the effect of mark_read. It clarifies the purpose of each parameter in a practical way.

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 'Pull fired events from your subscription feed,' clearly stating the verb and resource. It elaborates on what the events contain (source, citation_uri, raw payload) and provides filtering options, distinguishing it from siblings like list_subscriptions or recent_changes.

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

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

The description gives explicit filtering guidance by type and ISO timestamp, explains the mark_read flag, states that polling works fine, and mentions an alternative HTTP endpoint for scripts/dashboards. It does not explicitly contrast with siblings but provides clear usage context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds details about the parallel fan-out to sources, fallback from GDELT to GNews, and a soft-fail note for the USPTO source due to API sunset, providing 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 well-structured, front-loading example queries, then detailing functionality. It is comprehensive but slightly lengthy; however, given the complexity, it remains efficient and every sentence serves a purpose.

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

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

Despite no output schema, the description fully explains the return format (changes grouped by source, total_changes count, citation URIs), covers all parameters, and describes behavior including fallbacks and limitations. It is complete for the tool's complexity.

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

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

Schema coverage is 100%, and the description adds valuable context beyond the schema, such as explaining the 'since' parameter with both ISO date and relative shorthand examples, and recommending '30d' or '1m' for typical monitoring. It also clarifies that 'value' accepts 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 defines the tool as a change feed for a company in a specified time window, providing specific verb+resource combinations like 'What's new with X'. It distinguishes from the sibling tool 'entity_profile' by stating when to use that instead.

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

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

The description gives multiple example phrasings and explicitly recommends 'entity_profile' for static profiles. It explains the fan-out logic and fallbacks, though it could more explicitly state when not to use this tool.

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

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

Adds beyond annotations: storage scoping by identifier, persistence for authenticated users (permanent) vs anonymous (24 hours). Annotations already indicate idempotent and non-destructive, but description provides useful retention 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?

Five sentences, all essential. Front-loaded purpose, then usage, then behavior. No wordiness.

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 key-value store with two params and strong annotations, description covers purpose, usage, behavioral details (retention, scoping), and pairing with siblings. Complete.

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

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

Schema coverage is 100% with clear param descriptions. Description adds value via naming examples (e.g., 'target_ticker') and clarifies purpose of storage. Baseline 3, plus 1 for helpful examples.

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 'Save data the agent will need to reuse later', specifying verb 'save' and resource 'data'. It distinguishes from siblings by mentioning pairing with recall and forget.

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

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

Explicit guidance on when to use: 'when you discover something worth carrying forward... so you don't have to look it up again'. Also provides alternatives: 'Pair with recall to retrieve later, forget to delete.'

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description doesn't need to restate those. The description adds useful context about internal cascading through multiple lookup endpoints, which informs the agent about computational cost and return richness. 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 moderately concise, fitting important information into a few sentences. It front-loads with example queries for quick recognition, then states the core purpose and usage guidance, followed by detailed type descriptions. Every sentence adds value, though the examples could be slightly trimmed without loss.

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

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

Despite lacking an output schema, the description thoroughly explains what is returned for each entity type (ticker, CIK, company name, citation URI for companies; RxCUI, ingredient, brand, citation for drugs). It covers accepted input formats, mentions auto-disambiguation, and characterizes the internal cascading behavior. This is complete for an agent to understand inputs and expected outputs.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value by providing concrete examples for each enum value: for 'company' it explains auto-disambiguation and mentions citation URIs; for 'drug' it lists RxCUI, ingredient, brand, and citation. This clarifies what the 'value' parameter accepts beyond the schema's brief 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: resolving user-spoken names to canonical/official identifiers needed by other tools. It provides specific verbs ('resolve', 'look up') and examples ('ticker for...', 'CIK for...'), and distinguishes itself from sibling tools by emphasizing it replaces 2-3 manual lookups and should be used first when you have a name but need 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,' giving clear guidance on when to invoke this tool. It also explains that it replaces multiple manual lookups, implying it should be preferred over sequential individual lookups. No alternative tools are mentioned, but the guidance is direct and actionable.

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 safe read-only operation. Description adds that it probes each entity with ai_visibility_check internally and returns ranked list with score, confidence, signal density. No contradictions.

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

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

Two dense sentences: first states general purpose, second details function and use case. Every sentence adds value with no repetition.

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

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

Given no output schema, description adequately explains return fields. Covers internal mechanism and parameter roles. Missing error/limit info but acceptable for this 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%, but description adds useful nuance: first entity treated as subject for narrative. This enriches agent understanding beyond schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, probes with ai_visibility_check, and ranks results. It distinguishes from sibling ai_visibility_check by focusing on multiple entities.

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

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

Provides explicit use case (competitive AI-marketing audits) and an example. Does not explicitly state when not to use or list alternatives, but the context implies single-entity checks use ai_visibility_check.

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

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

The description adds significant context beyond annotations: potential 5-30s delay for new versions on Bundlephobia, graceful degradation with 'sources_failed' list, and composite nature. Annotations declare readOnly, idempotent, openWorld, and non-destructive, which the description aligns with and enriches.

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 front-loaded purpose, but it is somewhat lengthy (multiple sentences). However, every sentence provides valuable information, so it earns a 4 rather than 5 due to slight verbosity.

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

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

Given no output schema, the description thoroughly explains what is returned (summary block, advisories, links, alternatives, sources_failed). It covers edge cases like scoped packages, default version, partial failures, and timeouts, making it fully informative.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add new parameter-specific info beyond what's already in the input schema (scoped packages, default version). No extra semantics are introduced.

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 this is a composite check for deciding whether to add an npm package, combining deps.dev and bundlephobia data. It distinguishes itself from siblings like 'deep_research' by being specific to npm packages and providing a concise summary.

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 the agent asks about safety, popularity, size, or cost of an npm package. It also notes NPM-only in v1 and directs other ecosystems to deps.dev:version directly. This provides 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds context about the data source (Brussels Open Data) and return fields, which is useful but does not disclose behavioral traits beyond annotations.

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

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

The description is a single, efficient sentence that front-loads the purpose and includes key details without extraneous 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 adequately covers return values (dataset IDs, titles, themes, record counts) and the use of keyword search. Offset and pagination are left to schema, which is acceptable for a search 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 parameters are fully documented. The description adds some value by mentioning 'keyword' and the return of dataset IDs (linking to other tools), but does not add detail beyond schema descriptions.

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

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

The description clearly specifies the verb 'Search', the resource 'Brussels Open Data datasets', and the action of searching by keyword. It distinguishes from sibling tools like 'dataset_info' by noting that it returns dataset IDs for further 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?

The description indicates when to use the tool (for searching datasets by keyword) and hints at downstream usage (pass IDs to query/dataset_info). However, it lacks explicit exclusions or 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?

Goes beyond annotations to disclose technical details: 'BGE-base-en embeddings + cosine over 500-char overlapping windows', 'cap is 200K chars (longer inputs are truncated and flagged)', and that passages include 'character offsets' for verification. No contradiction with annotations (all readOnly/idempotent/etc. 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?

Concise paragraph with front-loaded purpose, then usage guidance, then technical details. Every sentence serves a purpose: purpose, use case, pairing, implementation, limits.

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?

Output is described (passages, offsets, scores) though no output schema exists. Truncation behavior is mentioned. Error handling and exact response format are omitted, but the description is adequate for a search tool with clear input 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%, but description enriches with examples (e.g., query examples like 'fiscal year 2024 revenue') and explains the internal retrieval mechanism (windows, embeddings) which adds value beyond schema. However, the core parameter details are already in the schema.

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

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

The description clearly states the tool performs 'semantic search INSIDE a fetched record', specifying inputs ('text you already pulled' and 'natural-language query') and outputs ('top-N passages with character offsets and similarity scores'). It distinguishes from the sibling 'ask_pipeworx_grounded' by explaining how they pair together.

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 using when 'the record is too big to cram into the prompt' and mentions pairing with 'ask_pipeworx_grounded'. Provides example queries like 'supply-chain risk'. Lacks explicit when-not-to-use scenarios but gives clear context.

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

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

Beyond annotations (readOnlyHint false, destructiveHint false), the description adds authentication requirements, delivery channel behaviors (SMS cap, phone verification, webhook with HMAC signing and auto-disable), all of which are valuable. It does not explicitly address idempotency despite the annotation hint, but overall adds substantial 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 well-structured, starting with the core purpose, then prerequisites, then options. Though somewhat dense, every sentence is informative. It could be slightly more concise, but it is clear and logically ordered.

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

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

The description covers prerequisites, types, delivery channels, and return value. However, it does not address idempotent behavior (despite the idempotentHint annotation) or error scenarios. For a tool of this complexity, a bit more detail on idempotency and validation would make it fully complete.

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

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

While the input schema already provides detailed parameter descriptions (100% coverage), the tool description adds business context and examples that help the agent understand usage. It summarizes delivery options and constraints, complementing the schema without redundancy.

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

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

The description opens with a specific verb and resource ('Create a proactive monitoring subscription'), clearly stating the tool's function. It distinguishes from sibling tools like list_subscriptions and unsubscribe, and explains the return value (subscription id). Supported types and delivery channels further clarify the 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?

The description explicitly states the prerequisite (Pipeworx OAuth account) and constraints (SMS cap, phone verification). It provides usage examples for each type, guiding selection. However, it does not explicitly contrast with alternative tools like ask_pipeworx, but the purpose is clear enough for a focused agent.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context: it returns categorized examples with tool call shapes, and is useful for learning how to call meta-tools. 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 detailed and informative but somewhat verbose, listing many example categories and uses. While every sentence adds value, it could be tightened slightly without losing meaning. Structure is good with clear topics and usage notes.

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

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

Despite lacking an output schema, the description fully explains what the tool returns: category-bucketed example questions with exact tool and argument shapes. It covers the single optional parameter, usage context, and the tool's role as an onboarding facilitator. No gaps.

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

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

Schema coverage is 100% for the single parameter 'topic'. The description enhances the schema by listing example values ('finance', 'pharma', 'betting') and explaining the effect of omitting or including the parameter, which aids the agent in selecting the correct invocation.

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

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

The description explicitly states the tool's purpose: it returns category-bucketed example questions and serves as an onboarding entry point. It uses specific verbs ('returns', 'shows', 'call') and distinguishes from sibling tools by focusing on example questions and getting started guidance.

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

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

The description provides explicit when-to-use guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you'. It also explains how to use the optional topic parameter for focused queries and when to omit it for a full spread.

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 a non-read-only write operation that is idempotent and non-destructive. The description adds the critical detail that subscriptions are deactivated, not deleted, preserving historical events. This is consistent with annotations and provides extra 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 two sentences, front-loaded with the action 'Cancel a subscription by id', and every sentence adds unique value (ownership, effect on row). No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description covers the purpose, ownership constraint, and side effect (deactivation). Combined with comprehensive annotations, it provides complete context for an agent to use correctly.

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

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

With 100% schema description coverage, the schema already documents the 'id' parameter as a UUID. The description adds that it's the ID returned by subscribe, which is helpful but minimal. 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 'Cancel' and clearly identifies the resource 'subscription by id'. It distinguishes itself from sibling tools like 'subscribe' and 'list_subscriptions' by explaining the reverse action and ownership enforcement.

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

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

The description provides explicit context on who can use it (own subscriptions only) and explains the effect (deactivation vs deletion). However, it does not explicitly state when not to use it or list alternative tools, though the sibling set includes 'subscribe' as a clear alternative.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds that it returns a verdict (with five options), a grounded actual value with citation, and reasoning. Also notes performance benefit of replacing 4-6 calls. 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 detailed but well-structured, starting with trigger phrases, use case, then technical details. Could be slightly more concise, but every sentence adds useful 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 complexity (two processing paths, return verdict options) and no output schema, the description thoroughly explains what the tool does and what it returns. It covers both financial and general claims.

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 value by explaining the tolerance_pct override and default behavior, as well as giving concrete claim examples. 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 defines the tool as a claim verifier with examples like 'fact check' and 'verify the claim that...'. It distinguishes from sibling tools by mentioning it replaces 4-6 sequential calls and handles both structured financial and general factual claims.

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 'Use whenever the agent needs to check whether something a user said is factually correct.' Provides context on claim types and processing paths. However, no explicit when-not-to-use or comparison to sibling alternatives like ask_pipeworx_grounded.

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