Ted Eu

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

Describes core behavior: routes across sources, picks the right tool, fills arguments, and returns results. Includes examples. Without annotations, it carries the burden well but could mention potential limitations or error handling.

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

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

Concise paragraph of ~5 sentences, front-loading the main purpose. Could be slightly more structured (e.g., bullet points), but efficient and clear.

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

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

Adequately explains what the tool does and provides usage examples. Lacks detail on return format or performance characteristics, but for a single-parameter 'ask' tool, 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 only parameter 'question' is richly documented in the description with extensive examples and context (e.g., 'What is the US trade deficit...'), going well beyond the schema's simple 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?

Clearly states the tool answers natural-language questions by selecting the appropriate data source. Distinguishes from siblings like search_notices or compare_entities by highlighting automatic routing across many sources.

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

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

Provides explicit when-to-use scenarios ('What is X?', etc.) and advises using this tool when the agent doesn't want to manually pick a Pipeworx tool. However, it does not explicitly state when not to use it or mention 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 declare read-only, open-world, non-destructive. Description adds detailed behavior: resolves market, classifies bet, fans out to specific packs per type, returns evidence packet and market-vs-model comparison. 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?

Front-loaded with core purpose. Dense but every sentence adds value. Slightly long (4 sentences) but justified by complexity. Could be trimmed slightly without loss.

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

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

No output schema, but description explains output sufficiently: evidence packet plus market-vs-model comparison. Covers the process (resolve, classify, fan-out) and outcome. Complete for the tool's complexity.

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

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

Schema has 100% coverage. Description enriches both parameters: clarifies market accepts slug, URL, or text; explains depth enum with 'quick' vs 'thorough' and default. Adds meaning beyond schema.

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

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

The description clearly states the verb 'Research', the resource 'Polymarket bet', and specifies it pulls Pipeworx data in one call. It distinguishes from siblings like ask_pipeworx and validate_claim by targeting betting research.

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

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

Provides explicit use cases: 'should I bet on X?', 'what does the data say?', 'is there edge?'. Does not state when not to use, but context implies it's purpose-built for Polymarket bets, making alternatives less relevant.

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?

With no annotations, the description discloses data sources (SEC EDGAR/XBRL, FAERS, FDA, trials) and return format (paired data + citation URIs). Also notes efficiency gain over sequential calls. Missing details on error handling or missing entities, but sufficient.

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

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

Concise at ~6 sentences with clear structure: purpose, trigger phrases, per-type details, return format, and efficiency note. No redundant information.

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

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

No output schema, but description lists specific fields for each type (revenue, net income, etc.; adverse events, approvals, trials). Could specify field names in output, but overall complete for tool complexity.

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

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

Both parameters are fully described in the schema (100% coverage). The description adds contextual examples (e.g., tickers like 'AAPL', drug names like 'ozempic') and clarifies data sources per type, enhancing schema 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 compares 2-5 companies or drugs side by side, with distinct data pulls per type. It distinguishes from sibling tools like entity_profile by focusing on multi-entity comparison.

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

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

Explicitly lists trigger phrases (e.g., 'compare X and Y', 'X vs Y') and use cases (tables/rankings). Does not specify when not to use, but the context is clear enough.

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

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

No annotations; description says it returns top-N tools but doesn't explain relevance determination or side effects. Adequate but not detailed.

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 packs useful info in a few sentences, each adds value. Slightly long but not wasteful.

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

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

No output schema, but description indicates return format (names+descriptions). Covers purpose, usage, and parameters well for a discovery 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 covers 100% of parameters with descriptions. Description adds query examples but mostly repeats schema info. 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?

Clearly states the tool finds tools by describing data or task, listing many example domains. Distinguishes from siblings by being a discovery meta-tool.

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

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

Explicitly advises to call first when many tools are available and wanting the option set. Examples of when to use are given, but no explicit when-not.

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?

With no annotations, the description adequately discloses behavior: it returns data with pipeworx:// citation URIs and lists the specific data types. It implies a read-only operation without side effects, though it doesn't mention limitations like pagination or caching.

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

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

The description is dense but front-loaded with purpose and use cases. Every sentence contributes useful information, though it could be slightly more concise by splitting into separate sentences for 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 complexity of aggregating multiple data sources and no output schema, the description thoroughly explains what is returned and why to use this tool. It addresses prerequisites (resolve_entity for names) and provides complete context for an agent to invoke correctly.

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

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

Schema coverage is 100% with good descriptions. The tool description adds value by clarifying valid inputs (ticker examples, CIK formatting) and providing a fallback direction (resolve_entity for names), enhancing understanding beyond the schema.

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

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

The description clearly states the tool's purpose: 'Get everything about a company in one call.' It specifies the types of data returned (SEC filings, fundamentals, patents, news, LEI) and distinguishes itself from siblings by noting it replaces calling 10+ pack tools across various domains.

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

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

Explicit usage scenarios are given: 'when a user asks "tell me about X"...' and when you would otherwise need multiple tools. It also specifies when not to use it (if only a name is available) and directs to use resolve_entity first, providing clear guidance on tool selection.

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

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

Describes deletion action but lacks details on permanence, idempotency (e.g., what if key doesn't exist), or error behavior. Adequate but not exhaustive for a tool with no annotations.

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

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

Two concise sentences, front-loaded with purpose, no wasted words.

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

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

Covers purpose, usage triggers, and sibling pairing. Lacks details on error handling or behavior for missing keys, but adequate for a simple tool with one parameter and no output schema.

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

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

Schema coverage is 100% and describes the parameter well. The description redundantly mentions 'by key' but adds no 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 uses specific verb 'Delete' and resource 'a previously stored memory by key', distinguishing it from sibling tools by mentioning pairing with remember and recall.

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

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

Explicitly states when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also recommends pairing with remember and recall, providing clear context.

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

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

With empty annotations, the description only conveys that the tool performs a fetch (read-only), but does not disclose error conditions, authorization needs, or other behavioral traits. The example helps, but more context would improve transparency.

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

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

Single sentence, no unnecessary words, front-loaded with verb and resource, conveys essential information efficiently.

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

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

Given the tool's simplicity (one parameter, no output schema), the description provides complete context for correct invocation.

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

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

Schema covers 100% of parameters with a format description. The tool description adds a concrete example ('123456-2025'), enhancing understanding beyond the schema.

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

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

The description clearly states the action (fetch) and resource (single TED notice) with a specific identifier (publication number) and an example format, distinguishing it from sibling tools like search_notices.

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

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

The description indicates when to use (when publication number is known) but lacks explicit when-not-to-use or mention of alternatives like search_notices, though contextually implied.

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?

No annotations are provided, but the description discloses important behavioral traits: rate-limiting (5 per identifier per day), free usage, no quota impact, and that the team reads digests daily. It doesn't mention if feedback is anonymous or public, but that is less critical.

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

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

The description is a single, well-structured paragraph with clear sections: purpose, usage, constraints. It is front-loaded with the main action and efficiently conveys all necessary information without redundancy.

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

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

Given no output schema and no annotations, the description covers all essential aspects: purpose, usage, behavior, parameter guidance, and constraints. It is sufficiently complete for an agent to correctly invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the enum options in context and providing guidance on how to write the message (e.g., 'Be specific which tool, what error'), which goes beyond the schema's parameter descriptions.

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

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

The description clearly specifies the verb 'tell' and resource 'Pipeworx team', and delineates the types of feedback (bug, feature, data_gap, praise). It distinguishes itself from sibling tools like 'ask_pipeworx' or 'discover_tools' by focusing solely on feedback.

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

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

The description explicitly states when to use the tool: 'when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog...', and provides constraints like rate-limiting and not pasting end-user prompts. This gives clear guidance on appropriate 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 indicate readOnly=true and no destruction. The description adds behavioral context: two modes, cross-event grouping, and return of 'ranked opportunities with suggested trade direction + reasoning.' No contradictions with annotations.

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

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

Description is about 7 sentences, front-loaded with the main verb and resource. It efficiently explains both modes without superfluous text. Minor improvement would be bullet-pointing modes for quicker scanning.

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

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

Given no output schema, the description adequately specifies return values (ranked opportunities with direction and reasoning). Parameter explanations are thorough, and behavioral coverage (two modes, cross-event detection) is 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%, so parameters are documented structurally. The description adds significant context to each parameter (e.g., 'event slug or full URL' for event, 'topic/seed question that searches across events' for topic), exceeding 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 description starts with a clear verb+resource: 'Find arbitrage opportunities on Polymarket by checking for monotonicity violations across related markets.' It distinguishes two modes (event vs topic) with examples, setting it apart from sibling tools like polymarket_edges.

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

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

Description explains when to use each mode: event mode for a single event slug, topic mode for cross-event searches. It includes a concrete scenario where event mode fails and topic mode succeeds (e.g., cutoff dates as separate events). Lacks explicit 'do not use' statements 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?

The description adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint, destructiveHint): it explains the lognormal model from FRED and live coinpaprika price, the process of grouping by asset, fetching price history once, computing probabilities, and ranking by edge. This details the algorithm and data freshness, fully aligning with annotations.

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

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

The description is a single moderate-length paragraph that front-loads the main purpose. It contains some redundant clauses but is efficient overall, avoiding unnecessary verbiage while covering the algorithm and use case.

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

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

Without an output schema, the description adequately explains the return value (top N ranked by edge magnitude with suggested trade direction) and comprehensively covers the internal process, data sources, and model details. It is complete for a discovery-oriented 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?

Input schema has 100% coverage with clear descriptions for all three parameters (limit, window, min_edge_pp). The description reiterates the purpose of the parameters in context but adds no new syntactic details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool scans highest-volume Polymarket markets, identifies where Pipeworx data disagrees with market price using a crypto-price model, and returns top edges with trade direction. It distinguishes itself from sibling tools like polymarket_arbitrage and bet_research by its specific focus on edge 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 explicitly frames the tool for the 'what should I bet on today' question, indicating opportunity discovery. It implies it avoids manual paging through markets, but does not explicitly state when not to use it or compare to alternatives like ask_pipeworx or entity_profile.

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?

With no annotations, the description carries full burden. It explains retrieval, listing all keys, and scoping. No mention of error handling for missing key, but still clear.

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 action, no fluff. Efficient and clear.

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

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

For a single-parameter retrieval tool with no output schema, description covers behavior, scoping, and relationship to siblings. Complete.

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

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

Schema covers 100% of parameters. Description adds value by explaining the special behavior when key is omitted (list all keys).

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

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

Clearly states the verb 'Retrieve' or 'list' and the resource 'saved values/keys'. Distinguishes from siblings 'remember' and 'forget'.

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

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

Explicitly says when to use: 'look up context the agent stored earlier'. Mentions alternatives: 'Pair with remember to save, forget to delete'. Gives scope context.

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

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

With no annotations, the description must convey all behavioral traits. It explains the parallel fan-out to three sources, accepted 'since' formats, and return structure (changes, count, URIs). It does not detail errors or rate limits, but the key behaviors are transparent.

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 and front-loaded with purpose. Every sentence contributes useful information (examples, data sources, parameter details, return format). No redundancy.

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

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

Given 3 required params and no output schema, the description covers all key aspects: input format, behavior (parallel fan-out), and output structure (changes, count, URIs). An agent has sufficient information to invoke the tool correctly.

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

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

Schema coverage is 100% (all 3 params described), but the description adds value by detailing the 'since' parameter's accepted formats (ISO date vs. relative shorthand like '7d', '30d') and the 'value' parameter's meaning (ticker or CIK). 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: retrieving recent changes for a company from multiple sources (SEC, GDELT, USPTO). It provides example user queries, distinguishing it from sibling tools like entity_profile or compare_entities.

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

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

The description explicitly maps user intents (e.g., 'what's happening?', 'any updates?') to the tool. While it doesn't list alternatives or exclusions, the context is clear enough for an agent to select this tool for monitoring recent changes.

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?

With no annotations, the description discloses scope (by agent identifier), persistence (authenticated persistent, anonymous 24 hours), and key-value storage. Lacking explicit mention of overwrite behavior on duplicate keys, but overall good coverage.

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

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

Four sentences, all adding value. Purpose is front-loaded. Could be slightly more compact, but each sentence earns its place.

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

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

For a simple save tool with two parameters and no output schema, the description covers purpose, usage, behavior, and relationships to siblings. No gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context on scoping and persistence beyond schema, though examples in schema already illustrate usage.

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

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

The description clearly states the tool saves data for reuse across conversations/sessions, specifying the action 'Save data' and the resource. It distinguishes from siblings by mentioning pairing with recall and forget.

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

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

Explicitly states when to use: 'when you discover something worth carrying forward' and provides examples. Also indicates when not to use by referencing alternative tools (recall, forget).

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

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

With no annotations, the description carries the full burden. It discloses the output (IDs plus citation URIs) and gives examples. However, it does not explicitly state whether the tool is read-only, mention rate limits, or describe error behavior. Still, it covers the main behavioral aspects.

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 only four sentences, each serving a distinct purpose: core purpose, usage context, examples, and additional workflow guidance. It is front-loaded with the main verb and resource, contains no repetition 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?

For a simple lookup tool with two parameters and no output schema, the description is remarkably complete. It covers purpose, input guidance, output format, workflow integration, and even the number of calls it replaces. No critical gaps remain.

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

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

Parameter schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the accepted input formats for 'value' (ticker, CIK, or name for companies; brand or generic name for drugs) and provides examples, exceeding the schema's minimal descriptions.

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

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

The description clearly specifies the verb 'look up' and the resource 'canonical/official identifier' for companies or drugs. It lists specific ID systems (CIK, ticker, RxCUI, LEI) and gives concrete examples. This distinctively separates it from sibling tools like 'compare_entities' 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 states when to use the tool ('when a user mentions a name and you need the CIK...') and positions it as a prerequisite for other tools that require official identifiers. It also notes that it replaces multiple lookup calls, providing clear usage context and alternatives.

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

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

Annotations are empty, so the description carries full burden. It implies a read-only search operation but does not confirm read-only status, discuss authentication, rate limits, or side effects. The description only states 'returns notice metadata' without behavioral guarantees.

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

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

The description is extremely concise: two sentences. The first sentence states purpose and method, the second lists return fields. Every sentence adds value with no waste.

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 10 parameters, no output schema, and no required fields, the description covers purpose, method, and return fields. It could mention pagination defaults or sorting, but otherwise provides sufficient context for a search tool.

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

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

The description adds meaning beyond the input schema by listing the return fields (e.g., publication number, title, buyer, etc.) which are not in the schema. The schema already has 100% coverage for each parameter, but the return field list provides valuable context for an agent invoking the tool.

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 'Search EU procurement notices' with specific verb (search) and resource, and explains the method 'Combine free-text query with structured filters'. It also lists return fields, distinguishing it from sibling 'get_notice' which likely retrieves a single notice.

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 when combining free-text and structured filters, but does not explicitly state when to use this tool vs alternatives like 'get_notice' or when not to use it. There is no exclusion or comparison, leaving some ambiguity for an AI agent.

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

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

With no annotations, the description fully informs the agent: it describes the return verdict types, extracted structured form, actual value with citation, and percent delta. It also explains it is a composite tool replacing multiple sequential calls. It does not mention any mutability, rate limits, or prerequisites, but the read-only nature is implied.

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 focused paragraph that front-loads the purpose and usage. Every sentence adds value: purpose, use cases, domain, return details, and efficiency benefit. No fluff or repetition.

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

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

For a tool with one parameter and no output schema, the description covers all necessary aspects: purpose, when to use, input format, domain, return structure, and even performance advantage. It is complete and leaves no ambiguity about what the tool does.

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

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

The only parameter (claim) has 100% schema coverage, and the description adds value by providing two concrete examples ('Apple's FY2024 revenue...', 'Microsoft made about $100B...') that clarify the expected format and domain. This goes beyond the schema's generic description.

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

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

The description clearly states the tool's purpose: fact-checking natural-language claims, with specific verbs like 'fact-check, verify, validate, confirm/refute'. It distinguishes itself from siblings by focusing on company-financial claims and using SEC EDGAR+XBRL sources. It also notes it replaces multiple sequential calls, reinforcing its specialized role.

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

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

The description explicitly advises when to use ('Use when an agent needs to check whether something a user said is true') and provides example queries. It also specifies the supported domain (company-financial claims), which implicitly excludes other claim types. However, it could be stronger by explicitly stating 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.