Latam Validate

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

Description adds key behaviors beyond annotations: mentions default model (Workers AI Llama-3.3-70b), optional Anthropic probing with BYO key and direct payment. No contradiction with readOnlyHint/idempotentHint.

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

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

Two concise sentences with front-loaded purpose, key behavior (default model, API key), and return structure. 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?

Describes return format (per-model scores, combined view) despite lack of output schema. Adequate for a moderate-complexity tool with 4 parameters.

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

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

Schema has 100% coverage; description adds context like default model for `models`, purpose of `_apiKey` (passed to Anthropic), and role of `context` for disambiguation.

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 a clear action: probe LLMs for knowledge about an entity and score visibility (0-100). It distinguishes itself from sibling tools like `scan_competitor_ai_presence` by focusing on per-model scoring and API key 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 states use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. Could improve by mentioning when not to use (e.g., for deep factual QA), but the listed scenarios are 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 read-only, open-world, idempotent, non-destructive. The description adds useful context beyond annotations: it routes dynamically, returns stable citation URIs, and works on every tier with 'one fast call.' However, it does not disclose limitations or failure modes, so it falls short of a 5.

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

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

The description is longer than average but front-loaded with 'PREFER OVER WEB SEARCH' and 'START HERE.' Every sentence provides distinct value: scope, mechanisms, triggers, examples, and alternatives. It is slightly verbose but every sentence earns its place for such a broad meta-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?

The tool takes only one natural-language question, and the description clearly explains its core behavior, return type (structured answer with citation URIs), and when to use alternatives. Without an output schema, it could have described the answer shape in more detail, but it is sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% description coverage for all parameters, all of which are documented as aliases for 'question.' The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool routes questions to one of 5,430 tools across 1,408 verified sources and returns a structured answer with citation URIs. It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by specifying when to 'step up' to those alternatives.

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

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

Explicitly instructs to prefer this tool over web search and states 'START HERE for most questions.' It provides concrete examples and explicitly names alternatives (ask_pipeworx_grounded, deep_research) with the conditions for using them, making when-to-use guidance exemplary.

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 meaningful context about beta/experimental status, live candidate routing, and the comparison process against the stable router, which is valuable beyond the annotations. No contradiction.

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

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

The description is a single, front-loaded paragraph that efficiently communicates the tool's nature, current state, usage instructions, and experimental status. Every sentence carries useful information without unnecessary fluff.

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

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

Despite lacking an output schema, the description references 'same response shape' as ask_pipeworx, setting expectations. It covers the experimental aspect, current candidate status, and usage context. Slightly verbose but 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?

The schema has 100% coverage, documenting all aliases for the 'question' parameter. The description only mentions 'same arguments' as ask_pipeworx, which reinforces but does not add new semantic meaning. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as a beta universal router identical to ask_pipeworx, with the same 5,430 tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx sibling by highlighting its experimental nature and candidate routing improvements.

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

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

Explicitly instructs to 'Use it exactly like ask_pipeworx when you want the newest routing', providing a clear use case and implicitly naming ask_pipeworx as the stable alternative. Also clarifies it is a full working router, not a fallback.

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

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

The description discloses substantial behavior beyond annotations: it returns either a success object with evidence/confidence/source or an explicit refusal with enumerated refusal_reason codes, it uses only the tool result to prevent hallucination, and it costs an extra LLM call. These traits are not present in the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint:false) and add critical context for the agent's decision-making. 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 information-dense but well-structured, front-loaded with the core purpose ('Hallucination-resistant answer mode for high-stakes reads'), then process, return format, refusal reasons, usage guidance, and cost tradeoff. Every sentence contributes, though the refusal_reason list makes it slightly long; still, it's not wasteful.

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

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

The tool has no output schema, so the description compensates by fully defining the return structure and refusal cases. It covers routing, grounding behavior, cost comparison, and use cases, making it 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?

Schema covers 100% of the 6 parameters with descriptions, all being aliases for the 'question' parameter. The description adds no additional parameter-level semantics, only reiterating the natural-language question in the usage context. Per the baseline for high schema coverage, score is 3.

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

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

Description states it's a 'hallucination-resistant answer mode for high-stakes reads' and explains it routes through 5,430 tools across 1408 sources, fetches data, and extracts answers only from tool results. It clearly distinguishes from ask_pipeworx by noting it's the same routing with an extra LLM call, making the purpose specific and sibling-differentiated.

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 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and provides examples (financial verdicts, legal claims, medical lookups, public statements). It also states 'prefer ask_pipeworx for casual lookups' and notes the extra LLM cost, giving 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 (readOnly, idempotent, non-destructive) are supplemented with extensive behavioral details: low-confidence short-circuit, closed/dead market handling, wide-spread warning, resolution-rule risk, resolver contract, parent event extractor, news fallback fields, and blocking behavior. No contradiction with annotations.

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

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

The description is lengthy (multiple paragraphs, dense with examples and edge cases). While well-organized with clear sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.), it could be more concise. The level of detail is appropriate for the tool's complexity, but it sacrifices brevity.

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

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

Given the tool's complexity (classifier, fan-out, resolver, parent events, news fallback, safety, cancellation rules) and no output schema, the description is remarkably complete. It covers response structure, edge cases, error handling, and practical caveats (e.g., resolution-risk). An agent has sufficient information to use the tool correctly.

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

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

Schema covers 100% of parameters with good descriptions. The description adds value by explaining the impact of `include_raw` (response size), the meaning of `depth` with quick vs thorough, and provides examples for the `market` parameter (slug, URL, question text). This extra context justifies a score above baseline 3.

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

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

The first sentence states the tool's purpose precisely: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It explains input types (slug, URL, question text) and the overall process (resolve, classify, fan-out, return evidence+comparison). This clearly distinguishes it from sibling tools like polymarket_edges or polymarket_arbitrage.

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 cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' Provides fan-out examples for various bet categories, giving clear context. Does not explicitly mention when not to use or compare with siblings, but the usage guidance is strong overall.

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 cover readOnlyHint, idempotentHint, destructiveHint=false. Description adds that data comes from central-bank registry but no additional behavioral details (rate limits, freshness). No contradiction with annotations.

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

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

Two sentences: first states purpose with fields, second gives usage example. No wasted words, front-loaded with key information.

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

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

For a simple lookup tool with 3 optional parameters and no output schema, description lists returned fields (COMPE, ISPB, name) and gives examples. Could mention ISPB definition or default limit, but adequate.

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

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

Schema coverage is 100%, so baseline is 3. Description adds real-world examples (code 1 → Banco do Brasil) and explains usage pattern (optional filter by name/code), providing extra value beyond schema.

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

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

Description clearly states it lists Brazilian banks with specific fields (COMPE, ISPB, name) and gives concrete examples (code 1 → Banco do Brasil). It distinguishes from sibling tools (no other bank lookup exists).

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

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

Explicitly says 'Use to resolve a bank code from a boleto or PIX/TED transfer'. Provides clear context for when to use. No explicit when-not or alternatives, but siblings don't overlap, so it's adequate.

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 idempotentHint=true, and the description adds value by specifying the returned data (street, neighborhood, city, state, coordinates) and giving an example.

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

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

The description is a single sentence with an example, highly concise, and front-loaded with the main 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?

For a simple read-only lookup with one parameter and no output schema, the description adequately explains input and output. Minor gap: does not mention error handling for invalid CEPs.

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 includes a clear example and format. The description repeats the example but adds no new information beyond the schema.

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

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

The description clearly states the tool's purpose: lookup a Brazilian CEP and return address details. It includes a specific example and distinguishes it from sibling tools like brasil_banks.

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?

While no explicit when-to-use guidance, the straightforward description and example imply usage for CEP lookup. No obvious alternatives among siblings, so no exclusion is needed.

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, idempotentHint, etc.), the description adds significant behavioral context: for companies it pulls real-time data from SEC EDGAR/XBRL with correct handling of off-calendar fiscal years; for drugs it pulls FAERS adverse-event counts, FDA approval counts, and active trial counts. It also notes results are sorted by primary metric and returns citation URIs. No contradictions with annotations.

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

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

At ~120 words, the description is information-dense and front-loads common query patterns. Uses bold emphasis and examples effectively. While efficient, it could be slightly more concise without losing meaning, but overall it earns its length.

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

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

Given the tool's complexity (comparison of 2-5 entities, two types with different data) and the absence of an output schema, the description covers intended use, alternative to sequential lookups, data sources, sorting, and return format (paired data + citation URIs). It is complete and leaves no major gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'type' parameter's effect (company vs drug) and providing concrete examples for 'values' (tickers/CIKs for companies, drug names for drugs). It also mentions edge cases like off-calendar fiscal years, enhancing understanding beyond the schema's enum and string descriptions.

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

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

The description starts with common query patterns and clearly states the tool's purpose: side-by-side comparison of 2-5 companies or drugs in a single parallel call. It specifies what each entity type retrieves (financial data from SEC for companies, FAERS data for drugs) and highlights that it replaces 8-15 sequential lookups, effectively distinguishing it from sibling tools like entity_profile.

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

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

The description explicitly instructs 'ALWAYS PREFER over sequential single-pack lookups when comparing entities,' providing strong guidance. It also describes behavior for queries like 'largest/most/biggest' but does not explicitly mention when not to use the tool (e.g., for more than 5 entities). Overall, it offers clear context on when to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and nondestructive behavior, and the description complements these with rich behavioral detail: decomposition into facets, parallel routing to 5,430 tools, explicit gaps[] for unanswered facets (never invented), second-hop iteration per depth, contradictions[] scan, record-level citations, and latency expectations. No contradictions with annotations.

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

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

The description is long but every sentence earns its place, covering account requirements, alternatives, depth behavior, output structure, and speed expectations. It is front-loaded with the most critical sign-in constraint and fallback. Slightly dense as a single wall of text, but the complexity of the tool justifies the length.

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

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

For a tool with 2 parameters, 100% schema coverage, rich annotations, and no output schema, the description is remarkably complete. It explains the return packet format (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation), the gaps[] and contradictions[] arrays, hop field semantics, and even latency ranges. An agent has everything needed to select and invoke the tool correctly.

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

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

The input schema already provides 100% description coverage for both parameters, but the tool description goes well beyond that. It elaborates the question field with examples of broad/multi-part questions and explains depth semantics (quick=3 facets, standard adds gap recovery, thorough adds lead-chasing plus contradiction scan), which adds significant meaning beyond the schema.

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

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

The description clearly states this is a grounded multi-source research tool over 1,408 structured data sources, decomposing questions into facets and routing them in parallel. It explicitly distinguishes itself from open-web search and its sibling ask_pipeworx, making its purpose unambiguous.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: it's 'Best for broad/multi-part questions over structured data', while single lookups should use ask_pipeworx, and breaking/current-news topics should also prefer ask_pipeworx. It also includes account prerequisites and fallback instructions, leaving no ambiguity about 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 and idempotentHint=true. The description adds valuable behavioral context: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' This discloses response format and usability beyond annotations. No contradictions.

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

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

The description is a single paragraph but well-structured, starting with the core purpose, then listing applicable domains, then explaining return value. It is not overly verbose for the information conveyed. Some agents might prefer bullet points for clarity, but it remains readable and efficient.

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

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

Given the tool's complexity (6 parameters, mostly aliases) and the presence of annotations covering safety, the description provides sufficient context: it explains the use case, return format (top-N tools with schemas), and how results are ready to call. No output schema exists, but the description covers the output sufficiently. Examples in the input schema further aid completeness.

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

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

Schema coverage is 100%, so parameters are fully documented. The description mentions that query accepts natural language and lists aliases (task, q, description, search) which are already in the schema. It adds examples but no additional semantic depth. Baseline 3 is appropriate as the description does not significantly augment parameter meaning.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists specific domains (SEC filings, financials, etc.) and distinguishes from siblings by saying 'Call this FIRST when you have many tools available and want to see the option set.' The verb 'discover' and resource 'tools' are precise.

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

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

The description explicitly says 'Use when you need to browse, search, look up, or discover what tools exist for: ...' and 'Call this FIRST when you have many tools available.' This provides strong guidance. It lacks explicit 'when not to use' but the context makes it clear that if you already know the tool, you wouldn't use this. The sibling list is large, so the tool fills a clear discovery niche.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds cross-source behavior, soft-fails, and limitations beyond annotations, but 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?

Description is long but well-structured: front-loaded with examples, then purpose, details, limitations. Every sentence adds value with minimal 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?

Covers return fields, limitations, and usage context. No output schema but lists expected fields. Missing details on pagination or error handling, but sufficient given 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 concrete examples ('AAPL', '0000320193') and clarifies that names are not supported, adding value beyond schema.

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

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

The description clearly states the tool aggregates a full cross-source profile of US public companies in one call, with specific verbs like 'profile' and 'research'. It distinguishes from siblings by explicitly favoring over chaining and mentioning resolve_entity for names.

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: 'ALWAYS PREFER over chaining single-pack lookups when user asks for holistic view' and instructs to use resolve_entity for names. Also notes soft-fail for patents.

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 readOnlyHint=false. The description reinforces the destructive nature ('Delete') and adds context about clearing sensitive data, which is helpful but not beyond what annotations provide. No contradictions.

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

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

Two sentences, front-loaded with the action, no wasted words. Every sentence provides value: action, usage context, and companion tools.

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 is complete. It covers purpose, usage triggers, and relationships. Annotations cover the destructive behavior, so no further elaboration needed.

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

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

Schema coverage is 100% for the single parameter 'key', with a clear description 'Memory key to delete'. The description does not add additional parameter details beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool deletes a memory by key ('Delete a previously stored memory by key'). It distinguishes from sibling tools 'remember' and 'recall' by explicitly mentioning pairing and contrasting operations.

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

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

The description provides explicit guidance on when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. It also suggests complementary tools ('Pair with remember and recall'), offering 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 already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds details about fetching the page, extracting title/description/key links, and outputting markdown format, which provides useful behavioral context beyond annotations.

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

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

The description is a single, well-structured paragraph with no wasted words. It front-loads the primary action and efficiently covers purpose and use cases.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description fully explains the input, process, and output format. No gaps or missing information.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds default and max for max_links, but this is marginal additional value. No significant new meaning beyond the schema.

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

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

The description clearly states it generates a llms.txt file for any URL, using a specific verb and resource. It distinguishes from siblings like scan_competitor_ai_presence by focusing on file generation for AI indexing.

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 lists explicit use cases (e.g., getting a client's site indexed, drafting for own project, auditing competitors), providing clear context for when to use it. It does not include exclusions or alternatives but 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, and destructiveHint. Description adds value by listing return fields (id, type, params, etc.) and usage context. No contradiction.

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

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

Two sentences: first states purpose and return fields, second gives usage guidance. 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 list tool with one optional parameter, description covers return fields and usage context. No output schema, but fields are listed. Adequate for agent use.

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

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

Schema coverage is 100% for the single boolean parameter. Description does not reiterate parameter details, but schema already covers it. 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?

States 'List the caller's active subscriptions' – specific verb and resource. Differentiates from sibling tools like subscribe and unsubscribe by mentioning review before adding more or finding id to cancel.

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 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Provides clear context for use, though doesn't explicitly state when not to use.

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

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

Annotations are all neutral (false), so the description carries the full burden—and it delivers. It discloses rate-limiting ('5 per identifier per day'), quota impact ('doesn't count against your tool-call quota'), human review cadence ('team reads digests daily'), and a privacy guideline about not pasting end-user prompts. This is context beyond what annotations provide.

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

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

The description is longer than average but every sentence carries useful information: purpose, usage trigger, exclusion criteria, disambiguation, message guidance, human-review context, and rate limit. It is front-loaded with the core purpose, and the structure is logical, though slightly verbose.

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

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

For a feedback tool with no output schema, the description covers all needed ground: what to report, when, how to phrase it, constraints, and what happens after submission. The nested context object is fully documented in the schema, and the description adds the missing contextual details about rate limits and review.

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 already well-documented. The description adds value by explaining how to write a good message ('Don't paste the end-user's prompt', '1-2 sentences typical') and by clarifying the type enum semantics with examples, which goes beyond the schema's short enum labels.

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

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

The description states a clear action—'Tell the Pipeworx team something is broken, missing, or needs to exist'—and names the resource (Pipeworx team). It also distinguishes this feedback tool from sibling tools by explicitly scoping it to tools served by this Pipeworx connection.

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 for each feedback type ('bug', 'feature/data_gap', 'praise') and explicitly says when NOT to use it: for tools from a different MCP server, directing users to file with that server instead. It even clarifies how to identify Pipeworx tools.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable context: data origin ('CF analytics-engine'), no PII, data structure ('just (pack, tool, count)'), and caching ('Cached 5min-1h depending on window'). There is 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 three sentences: purpose, use cases, data details. Every sentence adds distinct value, and the most important information (what the tool returns) is front-loaded. No unnecessary words.

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

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

Given low complexity (1 optional param, no output schema, rich annotations), the description covers data source, privacy, caching, use cases, and parameter guidance. It is complete for its scope.

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

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

The single parameter 'window' has full schema coverage (100%) with enum and description. The description adds semantic guidance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' and implies a default of '24h'. This goes beyond the schema.

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

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

The description clearly states the tool's purpose: 'What other AI agents are calling on Pipeworx right now. Returns the top tools, top packs, and total call volume over a recent window (24h, 7d, or 30d).' This specific verb+resource combination distinguishes it clearly from siblings like 'discover_tools' or 'ask_pipeworx'.

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

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

The description explicitly lists three use cases (discovering hot data sources, confirming canonical tool, aligning use case) and mentions caching behavior. While it does not include when-not-to-use or alternatives, the use cases provide clear context for appropriate invocation.

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 the description reinforces that the tool is analytical (no mutations). It adds extensive behavioral context: the logic of partition_sum checks, similarity anchors, placeholder filters, and the fill check against live CLOB depth. It also explains when results should not be traded (realizable_edge_pp ≤ 0). 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 detailed and well-structured, starting with the main purpose followed by mode-specific guidance, then response format. However, it is fairly long (several paragraphs) and includes technical jargon (Jaccard similarity, CLOB depth, placeholder fraction) that could be streamlined for quicker understanding. Still, 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 complexity (arbitrage detection with multiple modes, similarity checks, response structure with gaps, partition checks, fill checks), the description is remarkably complete. It explains the output fields, edge cases (skipped_low_similarity, placeholders), and when to consider the results actionable. No output schema exists, so the description appropriately covers return values.

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

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

Input schema covers 100% of parameters, but the description adds significant value: it explains that omitting both args triggers a trending scan, provides examples of valid event slugs and topic seeds, and details the internal logic for each mode (e.g., partition_check, Jaccard similarity). This goes well beyond the schema descriptions.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, with three distinct modes (trending scan, event-specific, cross-event topic). It is specific about the verb 'find' and the resource 'arbitrage opportunities on Polymarket'. The detailed behavior distinguishes it from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

The description explicitly explains when to use each mode: no args for trending scan, event for a specific market (recommended), topic for cross-event scanning. It provides guidance on what arguments to pass (event slug, topic seed) and when not to trade (realizable_edge_pp ≤ 0). It also mentions an alternative tool (polymarket_fill_risk) for custom sizing.

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

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

The description adds extensive behavioral context beyond annotations: caching (1h at KV level), diagnostics output (filter_skips), placeholder-slug filtering, and model details (e.g., lognormal barrier, GDELT news momentum). No contradiction with annotations.

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

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

The description is dense and well-structured with sections and parentheses, but it is somewhat verbose. Every sentence adds value, but it could be slightly trimmed without losing 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 complexity (9 parameters, no output schema), the description is thorough. It covers the three segments, edge calculation, knobs, diagnostics, and even the Fed market note. The only minor gap is the exact return format, but top-level fields are described.

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

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

Schema coverage is 100%, but the description adds significant extra meaning: explains tradeable-edge knobs, details on min_partition_leg_kelly (why min_kelly doesn't filter partitions), and gives context like slippage assumptions and default values. Schema alone would not convey this depth.

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: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It also specifies the use case ('what should I bet on today') and distinguishes from sibling tools by focusing on Pipeworx disagreement and opportunity discovery.

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

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

The description provides explicit guidance on when to use the tool (discovering opportunities without paging hundreds of markets) and explains filter knobs (min_liquidity, max_spread_pp, etc.). It does not explicitly contrast with siblings like 'polymarket_arbitrage' but implies differences through the focus on Pipeworx data.

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

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

Annotations declare readOnlyHint, idempotentHint, etc. The description adds beyond that: how data is computed (from daily snapshots, time-series, decay per day), what the response includes (tracked, expired, snapshot_dates), and limitations (snapshot gaps, not intraday). No contradiction.

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

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

The description is relatively long but each sentence adds value. It is front-loaded with the core question and structured response. A slight reduction in verbosity could improve conciseness, but it is still efficient.

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

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

Given no output schema, the description fully explains the response structure (tracked with time-series, trend, decay; expired with lifespan; snapshot_dates). It covers data source, computation, and limitations. For a read-only tool with two optional parameters, this is comprehensive.

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

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

Schema coverage is 100% with descriptions. The description adds meaning: days lookback default 14, max 30 (clamp 2-30), window specifies snapshot family (24hr, 1wk, 1mo). It explains the purpose of each parameter beyond the schema.

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

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

The description clearly states the verb (answers 'how long has this edge existed and is it shrinking?') and resource (edge persistence and decay telemetry from polymarket_edges snapshots). It distinguishes from sibling tools like polymarket_edges by focusing on time-series and decay 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 explicitly states the question the tool answers, implying when to use it (when longevity matters). It contrasts with sibling tools implicitly: fresh vs. old edges are different trades. It also notes limits (60-day TTL, daily closes) that guide usage.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: walks the ladder, reads CLOB depth, returns fill details and verdict. It warns about thin legs and directional risk, which goes beyond annotations. No contradictions.

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

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

The description is long but well-structured with sections (REQUIRES, SINGLE-MARKET, BASKET). It front-loads the purpose. Every sentence adds value, though some sentences are dense. Could be slightly more concise, but structure aids readability.

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

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

Given the tool's complexity (two modes, many output fields) and no output schema, the description is remarkably complete. It enumerates return fields for each mode, explains risks (thin legs, directional risk), and provides the 'capture_ratio' and 'clean_notional' details. No output schema needed.

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

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

Schema description coverage is 100% (all 4 properties described). The description adds significant meaning: explains mode-dependent behavior of side and size_usd, gives defaults, and clarifies interpretation differences between single-market and basket. This far exceeds the schema alone.

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

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

The description clearly states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It specifies two modes (single-market and basket) and what each returns. It distinguishes itself from sibling tools like polymarket_arbitrage by explicitly saying to use this before acting on those signals.

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

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

The description provides explicit when-to-use guidance: before acting on polymarket_arbitrage signals or trades above ~$500. It explains consequences of not using (partial fills, directional risk) and states requirements (one of market or event). Alternatives are implied via sibling tool names.

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

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

Beyond readOnlyHint annotations, the description details compatibility_warning conditions, temporal alignment, and skipped leg counters, providing deep insight into when spreads are meaningful.

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?

Dense with information, each sentence adds value; slightly long but well-structured with clear sections for modes, response, and safety fields.

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 response structure (leg prices, matched spreads, safety fields), covering all necessary context for correct use.

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

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

Schema coverage is 100% with descriptions, and the description adds context on how topic overrides work, enhancing understanding beyond the schema alone.

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

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

The description clearly defines the tool as a cross-venue spread calculator between Kalshi and Polymarket, distinguishing it from sibling tools by focusing on multi-market comparison.

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

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

Explicitly describes two modes (topic shortcuts and explicit tickers), explains when to use each, and warns that pre-mapped topics often return compatibility issues, guiding appropriate invocation.

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 the tool as read-only, idempotent, and non-destructive. The description adds useful context about scoping and pairing, but doesn't provide additional behavioral details beyond what annotations cover.

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 with no wasted words. The primary action is front-loaded, and every sentence adds value.

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

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

Given the single parameter with full schema coverage and no output schema, the description provides sufficient context: purpose, usage, scoping, and relationship to sibling tools.

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

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

Schema coverage is 100% with a clear description for the single parameter. The description repeats the parameter's behavior (omit to list all keys) without adding new semantic meaning beyond the schema.

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

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

The description uses specific verbs ('Retrieve', 'list') and clearly identifies the resource (values saved via remember). It explicitly distinguishes from siblings by naming 'remember' and 'forget' as paired tools.

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

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

States when to use: to look up context stored earlier, with concrete examples (target ticker, address, research notes). Mentions scoping and pairing, but does not explicitly exclude alternative tools.

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

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

The annotation set (readOnlyHint, idempotentHint, destructiveHint) already covers safety. The description adds valuable details: response fields (source, citation_uri, raw payload), the mark_read flag behavior (flagging events as read to filter next calls), and polling suitability, none of which 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—multiple sentences packed with useful information without redundancy. It is front-loaded with the main action and efficiently covers purpose, parameters, behavior, and alternative access.

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

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

Although there is no output schema, the description explains that each alert carries source, citation_uri, and raw event payload. It also mentions polling and an alternative GET endpoint. For a simple read-only tool, this is sufficient; a fully detailed return structure would earn a 5.

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

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

With 100% schema coverage, the baseline is 3. The description adds context beyond the schema, such as example filter values (e.g., 'sec_8k') and clarifying that mark_read flags events as read to show only newer ones on subsequent calls, enhancing parameter understanding.

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

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

The description clearly states the tool pulls fired events from the user's subscription feed, specifying the verb 'pull' and the resource 'subscription feed'. It distinguishes itself from siblings like 'list_subscriptions' and 'recent_changes' by focusing on recent alerts.

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

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

The description notes that polling works fine and mentions an alternative REST endpoint for scripts and dashboards, providing context on when to use the tool. However, it lacks explicit guidance on when not to use it relative to 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 declare readonly and idempotent. Description adds fan-out to multiple sources, fallback logic from GDELT to GNews, soft-fail for USPTO, and return structure with citation URIs. No contradiction with annotations.

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

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

Long but efficiently structured with example queries upfront. Every sentence adds information. Could be slightly more concise, but complexity justifies length.

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

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

Given 3 params and no output schema, the description explains return structure, sources, fallback, and provides an alternative. Covers edge cases like USPTO sunset. Complete for the tool's purpose.

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

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

Schema coverage 100% gives baseline 3. Description adds practical examples for 'since' (e.g., '30d'), explains 'type' is only 'company', and clarifies 'value' accepts ticker or CIK. Adds value beyond schema.

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

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

The description clearly states it provides a change feed for a company in a date window, listing sources and output. It distinguishes from sibling 'entity_profile' by specifying when to use the alternative.

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 example queries show when to use, and the description directly says 'Use entity_profile instead when you want the static profile', giving clear when-not and 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?

Adds key behavioral details beyond annotations: scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous sessions. 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?

Three sentences, front-loaded with main purpose, then usage guidance, then behavioral details. 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, and behavior well. Lacks mention of return value or overwrite behavior, but annotations and simplicity make it acceptable.

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 parameter descriptions are adequate. The description adds context but does not elaborate on parameter details beyond the schema.

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

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

The description clearly states the verb ('Save') and resource ('data') and explicitly distinguishes from sibling tools '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?

It provides explicit guidance: 'Use when you discover something worth carrying forward' and explains pairing with recall/forget. Also mentions persistence differences.

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. Description adds value by detailing internal cascading behavior, auto-disambiguation, and return values including citation URIs. No contradictions.

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

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

Well-structured with examples upfront, followed by supported types and internal behavior. Every sentence adds value. Slightly long but informative; no wasted words. Front-loaded effectively.

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

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

Despite no output schema, the description explains return values comprehensively (ticker, CIK, company_name, citation URI for company; RxCUI, ingredient, brand for drug). It fully covers input and output behavior for a 2-parameter resolution tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the enum values ('company', 'drug') with concrete input examples (ticker, CIK, name; brand/generic) and mentioning auto-disambiguation. It clarifies what each type expects.

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 and resources: 'resolve a user-spoken NAME to the canonical/official identifier'. It provides concrete examples (ticker, CIK, RxCUI) and distinguishes from sibling tools by focusing on name-to-ID conversion. No tautology.

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 'Use FIRST whenever you have a name but need an ID.' This gives clear when-to-use guidance. It also notes that it replaces 2-3 manual lookups. Lacks explicit when-not-to-use, but the context strongly implies usage.

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

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

Annotations already set readOnlyHint, idempotentHint, etc. Description adds significant detail: that it probes each entity with ai_visibility_check, ranks by score, surfaces most/least recognized, and returns score, confidence, signal density per entity.

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

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

Four sentences with no wasted words. First sentence captures core purpose, followed by brief behavioral details and a concrete use case. Efficient and well-organized.

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

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

Given the tool's complexity (multi-entity, internal probe), the description covers what it does, how it works (calls ai_visibility_check), and what it returns (ranked list with scores). Lacks explicit format or definition of 'signal density', but sufficient for a tool that delegates. No output schema, but description compensates well.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by noting that the first entity in the array is treated as the 'subject' for narrative, and that context is shared across probes. This goes beyond schema descriptions.

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

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

Description clearly states 'Compare AI visibility across multiple entities side-by-side' with specific verb (compare) and resource (AI visibility). It distinguishes from sibling ai_visibility_check by emphasizing batch comparison and ranking.

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

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

Provides explicit use case ('competitive AI-marketing audits') and example question. Does not explicitly mention when not to use or alternative tools like ai_visibility_check for single entities, but context implies it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: partial failure behavior (bundlephobia can take 5-30s, sources_failed will list it), graceful degradation, and the composite nature of the call. No contradictions with annotations.

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

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

The description is relatively long but each sentence provides useful information. It is front-loaded with the main purpose and then details behavior. Could be slightly more concise, but no wasted content.

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

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

Even without an output schema, the description thoroughly documents the return fields (summary block with is_latest, license, etc., per-advisory detail, links, alternative versions). It also covers edge cases (scoped packages, default version, timeout behavior). Very complete for a read-only 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% for both parameters. The description adds context that 'package' accepts scoped names (e.g., '@types/node') and that 'version' defaults to latest when omitted. This adds marginal value beyond the schema descriptions.

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

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

The description clearly states the tool is a composite check for evaluating npm packages, covering license, advisories, version history, and bundle size. It distinguishes from sibling tools by mentioning NPM ecosystem only and referencing 'deps.dev:version' for other ecosystems.

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also notes that PyPI/Maven/Cargo/Go fall under a different tool ('deps.dev:version'). This provides clear when-to-use and alternative 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, destructiveHint. Description adds technical details: 'BGE-base-en embeddings + cosine over 500-char overlapping windows', truncation flag for >200K, and output format (passages with offsets and scores). 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?

Compact 80-word description with three focused sentences: first states purpose, second gives usage guidance, third provides technical implementation details. Every sentence is informative. 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?

Given no output schema, description covers input parameters, behavioral details (embedding model, window size, character limit), output format (passages with offsets and scores), and links to sibling tool ask_pipeworx_grounded. Fully sufficient for agent to use correctly.

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

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

Schema covers 100% of parameters. Description clarifies text as 'document text to search inside (max ~200K chars)', query as natural-language with examples, and limit as 'Max passages to return (1-20, default 5)'. Adds value beyond schema by explaining output structure (offsets, scores) and retrieval mechanics.

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

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

Clear verb+resource: 'Semantic search INSIDE a fetched record.' Distinguishes from siblings by explaining it searches inside a pre-fetched document, unlike ask_pipeworx_grounded which grounds over passages. Includes specific examples like 'SEC 10-K body'.

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

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

Explicitly states when to use: 'Use when the record is too big to cram into the prompt.' Mentions pairing with ask_pipeworx_grounded for grounding. Also describes input cap (200K chars) and truncation 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?

The description adds significant behavioral details beyond annotations, such as the need for a Pipeworx OAuth account, type-specific parameters, SMS delivery cap, webhook auto-disable after 10 failures, and the one-time signing secret. Annotations only indicate idempotency and non-destructiveness, which are consistent.

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

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

The description is fairly concise given the complexity, with well-structured sentences covering purpose, requirements, types, and delivery. It could be slightly shorter, but it is efficient and front-loaded with the main action.

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

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

Given the tool's complexity (3 parameters, nested objects, no output schema), the description is very complete, covering all necessary details: account requirements, type-specific params, delivery options, limitations (caps, auto-disable), and security (signing). It leaves no significant 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%, and the description adds detailed semantics for each parameter, including type-specific structures, examples, and constraints (e.g., SMS must be verified, webhook HTTPS only). It provides more value than the schema alone, justifying a 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 creates a proactive monitoring subscription to a live-data event stream and returns the new subscription ID. It distinguishes this from sibling tools like list_subscriptions and unsubscribe by focusing on subscription creation.

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

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

The description provides clear context on when to use the tool, including OAuth account requirements, supported types with examples, and delivery channel options. It does not explicitly state when not to use it, but the context is sufficient for an agent to decide.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds value by explaining it returns example questions with tool calls and is an onboarding tool. 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?

Description is moderately long but efficiently packed with useful info: trigger phrases, output description, usage instructions. Could be slightly trimmed but not verbose.

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

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

Given the tool's simplicity (one optional param, no output schema), the description covers all needed aspects: what it returns, when to use, and how to use the param. Sibling context and annotations complement it well.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning beyond schema by listing possible topic values (finance, pharma, etc.) and explaining omission behavior ('full spread'). This extra context justifies a 4.

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

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

The description clearly states the tool is an onboarding entry point that returns category-bucketed example questions with exact tool+argument shapes. It uses specific verb 'returns' and distinguishes from siblings like ask_pipeworx by noting it should be used first when unsure what Pipeworx can do.

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 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools'. Also explains when to omit or pass a topic. Does not explicitly state when not to use, but context is clear.

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

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

Annotations indicate non-read-only, idempotent, and non-destructive. The description adds ownership enforcement and deactivation (not deletion) details, which go beyond annotations and inform agent about side effects and data persistence.

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

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

Two sentences, front-loaded with action and key constraints. No superfluous words; every sentence adds value.

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

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

While the description is clear about the effect, it omits any indication of the return value (e.g., success confirmation, count). Given no output schema, this is a minor gap for completeness.

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

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

The sole parameter 'id' has 100% schema description coverage. The description only mentions 'by id' without additional semantic detail, so it does not significantly enhance what the schema already provides.

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

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

The description clearly states the verb ('Cancel') and resource ('subscription by id'), and distinguishes from sibling tools like 'subscribe' (create) and 'list_subscriptions' (read). It also specifies ownership enforcement and deactivation behavior, adding specificity.

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

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

The description provides clear context: ownership is enforced (only own subscriptions), and deactivation preserves historical events accessible via 'recent_alerts'. This helps the agent decide when to use this tool versus deletion or other operations.

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 false. The description adds value by detailing the decoding behavior (bank code, plaza, account number) and bank name resolution. 'Pure computation' aligns with annotations, and no contradictions are present.

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

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

The description is three concise sentences, front-loaded with the core purpose. Every sentence adds value with no redundant or filler content.

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 validation behavior and input flexibility but omits any mention of the output format or return value. Given the lack of an output schema, this gap reduces completeness for an AI agent that needs to interpret results.

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

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

Schema coverage is 100%, so baseline is 3. The description adds behavioral context about what the tool does with the parameter (checksum, decoding) but does not significantly enhance parameter semantics beyond the schema's format 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 validates a Mexican CLABE, checks the control-digit checksum, decodes bank code, plaza, account number, and resolves bank names. It is specific and distinguishes itself from sibling validation tools like validate_cpf and validate_cnpj.

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

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

The description provides clear context for when to use this tool (for Mexican CLABE validation) and notes that it is a pure computation accepting spaces/dashes. It does not explicitly mention alternatives or exclusions, but the specificity makes usage intuitive.

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, etc. The description adds value by detailing the return format (verdict with five possible values, actual value with citation, reasoning) and the two processing pipelines. It also mentions exact percent-delta math for financial claims. No contradictions with annotations.

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

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

The description is front-loaded with example queries and is well-structured. Every sentence provides useful information: examples, pipeline details, return format, and efficiency gains. It is slightly longer than average but not verbose, earning its length.

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

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

Given the tool's complexity, the description covers the two processing paths, the return format, and the kinds of claims handled. It does not detail what constitutes 'authoritative sources' beyond SEC EDGAR and 'live sources,' but is sufficient for an agent to understand the tool's capability. No output schema exists, so the description provides necessary output context.

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

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

Schema coverage is 100% (both parameters described). The description adds meaning beyond the schema: for tolerance_pct, it explains default behavior ('implied by wording, capped at 5') and suggests setting 1-2 for hallucination detection. It also clarifies that claim is a natural-language statement.

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: to verify natural-language factual claims against authoritative sources. It provides example queries and distinguishes two processing paths (SEC EDGAR for company-financial claims, grounded pipeline for others). This differentiates it from sibling tools like deep_research or entity_profile.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It explains when to use the financial path vs. the grounded pipeline and notes that it replaces 4-6 sequential calls. However, it does not explicitly state when not to use it or what alternatives to consider for non-factual claims.

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=false. The description adds valuable context: support for numeric and alphanumeric CNPJ, punctuation acceptance, and the skip_lookup flag behavior. No contradictions.

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

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

Three sentences, front-loaded with the primary purpose. Every sentence adds value: validation + lookup, format details, skip_lookup option. No unnecessary words.

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

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

The description covers the main functionality and parameters well. No output schema, but the description mentions what data is returned. For a simple validation tool with annotations, this is nearly complete. Minor gap: no mention of error handling or status codes.

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 includes detailed descriptions. The description adds minor context (checksum support, punctuation) not present in schema for the cnpj param, but otherwise does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it validates a Brazilian CNPJ and looks up company registration details. It uses specific verbs (validate, look up) and identifies the resource (CNPJ). The sibling tools include validate_cpf and validate_clabe, so the target entity is distinct.

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

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

The description implies when to use (to validate a CNPJ) but does not explicitly compare to siblings or state when not to use. It could mention, for example, that validate_cpf is for individual tax IDs. The guidance is adequate but not explicit.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds behavioral traits: it is a pure computation (no lookup), returns check-digit correctness and formatted form, and accepts punctuation. This adds value beyond annotations without contradiction.

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

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

The description is concise: two efficient sentences that front-load purpose and behavior. Every sentence adds value with no redundancy or 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?

Given the tool's simplicity (one parameter, clear annotations, no output schema), the description covers the essential aspects: what it does, how it works, acceptable input, and what it returns. It could mention return structure more explicitly, but overall it is sufficiently complete.

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

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

The input schema covers the parameter fully with description and examples. The description confirms accepted formats (with punctuation) but adds no extra semantic information beyond what the schema already provides. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly identifies the tool's purpose: validating the checksum of a Brazilian CPF. It specifies the resource (CPF), the verb (validate), and scope (checksum computation, no lookup). It distinguishes from sibling tools like validate_cnpj and validate_clabe by being CPF-specific.

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

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

The description implies usage context: use it when you need to validate CPF checksum computationally. It mentions 'no lookup' which hints at limitations, but does not explicitly state when not to use it or provide alternatives. Given sibling tools exist, the context is clear enough.

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