Dwds

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

Annotations already indicate readOnlyHint, openWorldHint, and destructiveHint. The description adds that it returns structured answers with citation URIs, which goes beyond annotations. It does not mention potential latency or failure modes, but the disclosure is strong.

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

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

The description is front-loaded with the key directive 'PREFER OVER WEB SEARCH' and is well-structured, but it is somewhat verbose with many examples. Every sentence serves a purpose, but could be condensed slightly.

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

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

Given the tool has a single parameter, no output schema, and annotations covering safety, the description is complete. It explains the tool's purpose, when to use it, scope of questions, and return format (structured answer with citations).

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 describes 'question' as a natural language string. The description enriches this by specifying that it handles questions about a wide range of topics (stocks, weather, patents, etc.), implying the parameter accepts complex factual queries.

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

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

The description clearly states that the tool routes questions to one of 1,423+ tools and returns structured answers with citations. It explicitly distinguishes itself from web search and sibling tools like discover_tools.

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

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

The description provides explicit guidance: 'PREFER OVER WEB SEARCH', lists specific use cases (SEC filings, FDA data, etc.), and gives example query patterns ('what is', 'look up'). It tells the agent when to use this tool over 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?

The description adds substantial behavioral context beyond the annotations (readOnlyHint, openWorldHint, destructiveHint). It details the resolution, classification, fan-out process with specific examples (crypto+fred+gdelt for BTC, etc.), and the evidence packet plus market-vs-model comparison. 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 well-structured and front-loaded with the main action. Every sentence adds necessary detail, though slightly verbose with examples of fan-out packs. Could be trimmed without losing clarity, but remains effective.

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

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

Given the tool's complexity (multiple input types, classification, dynamic fan-out, comparison) and absence of an output schema, the description is remarkably complete. It explains the end-to-end process, the depth parameter's impact, and the return value. Covers all essential aspects for an agent to use it 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?

Both parameters are fully described in the schema (100% coverage). The description adds value by clarifying the market parameter's three input types with examples, and explaining the depth parameter's options ('quick' vs 'thorough') and default behavior. This exceeds 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's purpose: researching a Polymarket bet by pulling Pipeworx data. It specifies the three acceptable input formats (slug, URL, question text) and the output (evidence packet + market-vs-model comparison). It distinguishes itself from siblings by noting it is the core demo product and that agents using it convert better than those discovering packs manually.

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

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

The description provides explicit use cases: 'should I bet on X?', 'what does the data say about this Polymarket market?', 'is there edge in this bet?'. While it does not name specific alternatives, the context of sibling tools (e.g., validate_claim, polymarket_edges) implies when not to use it. A clear when-not-to-use statement would elevate this to a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds data sources (SEC EDGAR/XBRL, FAERS, etc.), return format (paired data + citation URIs), and per-type details. 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 structured: first sentence states core purpose, then usage triggers, then per-type details, then return info. Some redundancy but overall concise and front-loaded. Could be slightly tighter.

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

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

Covers two entity types with multiple data sources, usage guidance, and return description. No output schema, but return format described. Adequate for complexity. No missing critical details.

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. Description further explains what each type value does (company: revenue, net income, etc.; drug: adverse events, approvals, trials) and gives example formats for values (tickers, drug names). Adds meaning beyond schema.

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

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

Clearly states 'Compare 2–5 companies (or drugs) side by side in one call.' It provides specific verb and resource, and distinguishes from siblings like entity_profile (single entity) and bet_research (gambling).

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 user queries that trigger use: 'compare X and Y', 'X vs Y', 'how do X, Y, Z stack up', 'which is bigger', or wants tables/rankings. Mentions tool replaces 8–15 sequential calls, implying alternative. Doesn't 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 already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. However, it adds no behavioral context such as return format, pagination, or rate limits, missing an opportunity to clarify operational behavior.

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

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

The single-sentence description is concise and front-loaded, but it is too brief to be maximally helpful. While no words are wasted, the lack of detail means the sentence does not fully earn its place.

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

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

Given the tool's complexity (3 parameters, no output schema), the description is incomplete. It fails to explain the nature of a concordance search, query syntax, parameter roles, or expected results, leaving significant gaps for an agent to infer.

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 only 33% schema description coverage, the description should compensate by explaining parameters. It does not mention 'query,' 'limit,' or 'corpus' at all, leaving the agent without guidance on how to construct valid inputs beyond the minimal schema hints.

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 'Search the DWDS corpus,' which clearly identifies the action (search) and resource (DWDS corpus). However, it does not distinguish this tool from sibling tools like 'kwic' or 'snippet,' which may also perform searches within the same corpus, leaving ambiguity about the specific type of search.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any usage restrictions or prerequisites. The description does not mention any conditions or exclusions, relying solely on the agent to infer usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns 'top-N most relevant tools with names + descriptions,' but does not disclose additional behavioral traits like rate limits or auth needs. With annotations covering safety, the description provides adequate but not extensive context.

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

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

The description is front-loaded with the core purpose and uses a list for domains efficiently. While slightly verbose with the list, every sentence contributes meaning. It is well-structured for quick comprehension.

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, but the description explicitly states 'Returns the top-N most relevant tools with names + descriptions,' which fully covers return value expectations. For a discovery tool with simple inputs, this is complete.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining that 'query' is a natural language description with examples, and specifies default and max for 'limit.' This enriches the schema information.

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 indicates it returns top-N relevant tools, making it distinct from sibling tools which are more specific like bet_research 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 advises to 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' providing clear guidance on when to use. It also includes 'Use when you need to browse, search, look up, or discover what tools exist for,' though it lacks explicit when-not-to-use scenarios.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds behavioral context by listing the specific data sources returned (SEC filings, fundamentals, patents, news, LEI) and mentions pipeworx:// citation URIs. It does not contradict annotations.

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

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

The description is dense but efficient, about 150 words with no wasted sentences. Front-loaded with purpose and usage guidance.

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 having no output schema, the description fully enumerates the return data types: 'Returns recent SEC filings, latest revenue/net income/cash position fundamentals, USPTO patents... recent news mentions, and the LEI.' This is complete for the agent to understand the tool's output.

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

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

Schema coverage is 100%. The description enriches parameters: explains that type is only 'company' for now, and value can be ticker or CIK, and also clarifies that names are not supported. This adds meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Get everything about a company in one call.' It lists specific user queries that trigger its use and differentiates from siblings by noting it replaces calling 10+ pack tools, and explicitly distinguishes from resolve_entity.

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

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

Explicit usage guidance: 'Use when a user asks... or you'd otherwise need to call 10+ pack tools.' Also provides when-not-to-use: 'Names not supported — use resolve_entity first.' This clearly helps the agent select the correct tool.

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

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

Annotations already declare destructiveHint=true. Description adds context about clearing sensitive data and that it deletes by key, aligning well without contradiction.

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

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

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

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

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

For a simple one-parameter tool with good annotations and no output schema, the description fully covers purpose, usage, and behavior.

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

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

Schema coverage is 100%, so the description does not need to add much. It mentions 'by key' which matches the schema's 'key' parameter, but adds little extra 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 the verb 'Delete' with the resource 'previously stored memory by key', which is specific and clearly distinguishes it from siblings '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 suggests pairing with 'remember' and 'recall', implying 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds no behavioral context beyond implying a readonly view, missing details like result format or pagination.

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 three words, which is concise but severely under-specified. It lacks essential information about parameters and behavior, making it insufficient.

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 three parameters and no output schema, the description is too minimal to be complete. It does not explain the query syntax, limit semantics, or corpus selection, though annotations provide some safety context.

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

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

Schema description coverage is 0% and the description does not mention any parameters. Three parameters (limit, query, corpus) are completely undocumented, providing no 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 'Keyword-in-context view' clearly indicates the tool provides a KWIC view, but it does not differentiate it from sibling tools like 'snippet' or 'corpus_concordance', which may also present text in context.

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

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

No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, such as when a normal snippet suffices or when corpus-wide concordance 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the input-output mapping but no additional behavioral details (e.g., language support, edge cases, error handling). Minimal value added 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 maximally concise: a single phrase with no redundant words. It communicates the core purpose efficiently, earning top marks for conciseness.

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

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

Given a simple tool with one parameter and no output schema, the description covers purpose and parameter semantics but omits usage guidelines and behavioral details. It is adequate for a basic tool but not fully complete.

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

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

The schema has 0% description coverage; the parameter 'form' is undocumented. The description states 'form → base form,' which clarifies that the parameter is the input word form. This adds essential meaning that the schema lacks, though it is brief.

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 operation as 'Lemma resolution' and defines it as transformation from a word form to its base form, which is specific and matches the tool name. However, does not distinguish from sibling tools like 'resolve_entity' but is adequate.

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

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

No guidance is provided on when to use this tool versus alternatives. No mention of prerequisites, context, or when not to use it. The description lacks any usage direction.

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?

While annotations provide minimal behavioral info, the description discloses key traits: rate-limited to 5 per identifier per day, free, and does not count against tool-call quota. It also implies the tool is for communication rather than data mutation, adding value beyond annotations.

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

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

The description is a focused 4-sentence paragraph. It front-loads the core purpose, then covers usage conditions, formatting tips, and constraints. Every sentence provides essential information with no redundancy.

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

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

Given the tool's simple nature (submitting feedback), the description is fully adequate. It covers what the tool does, when to use it, how to use it (including parameter usage hints), and operational constraints (rate limit, quota). No output schema needed for such a 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 has 100% coverage, but description adds context: defines each enum value for 'type', provides formatting guidelines for 'message' (be specific, 1-2 sentences, 2000 chars), and explains when to use 'context'. This augments 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's purpose: to report bugs, request features/data_gaps, or give praise to the Pipeworx team. It uses specific verbs and resources, distinguishing it from siblings which are all about data retrieval or analysis.

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

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

Provides explicit when-to-use guidance: for bugs, missing features, data gaps, and praise. Also advises on how to format feedback (mention tools/packs, not end-user prompts) and notes rate limits and quota exemption. This comprehensively informs agent decision-making.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate those. It adds behavioral context by describing the two modes, how it 'walks' markets and checks ordering, and what the output contains. It does not contradict annotations.

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

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

The description is a single paragraph but efficiently conveys the tool's purpose, modes, and output. It is front-loaded with the main action and uses straightforward language. A bit more structure (e.g., bullet points for modes) could improve, but it is concise without being terse.

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 lack of an output schema, the description adequately explains that the tool returns 'ranked opportunities with suggested trade direction + reasoning.' It covers both input modes and their contexts, providing complete guidance for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so the schema already describes both parameters. However, the description adds significant value by explaining the purpose of each parameter (single-event vs. cross-event mode) and providing examples. This goes beyond bare schema definitions.

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

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

The description clearly states it finds arbitrage opportunities by checking monotonicity violations on Polymarket. It distinguishes two modes (event and topic) with specific explanations, and the tool name itself conveys purpose. This differentiates it from siblings like 'bet_research' or 'polymarket_edges'.

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

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

The description explicitly explains when to use each mode: 'event' for a single event slug, 'topic' for cross-event scenarios. It provides an example for topic mode and explains why cross-event mode is necessary. While it doesn't explicitly say when not to use, 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?

The description provides extensive behavioral details beyond annotations: it explains the model (lognormal from FRED + coinpaprika), the process (scans, groups, fetches history once, ranks by edge), and output (top N with trade direction). This far exceeds the minimal safety info from annotations.

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

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

The description is moderately long but well-structured: purpose first, then technical details, then output summary. Every sentence adds value, though slight tightening might improve conciseness.

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

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

Without output schema, the description adequately explains return values ('top N ranked by edge magnitude with suggested trade direction'). Input and process are clearly described, making the tool understandable for an agent.

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

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

Schema descriptions cover all three parameters fully (100% coverage). The description adds 'Returns top N ranked by edge magnitude' which relates to limit, but does not significantly enhance understanding beyond the schema.

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

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

The description starts with a specific verb ('Scan') and resource ('highest-volume Polymarket markets'), and clearly states the unique function: returning markets where data disagrees most with market price. It differentiates from sibling tools by focusing on edge-based 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 explicitly states the tool is built for 'what should I bet on today' and helps discover opportunities without manual browsing. It clearly implies when to use but does not explicitly exclude contexts or mention sibling tools as 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 and non-destructive nature. Description adds scoping context (anonymous IP, BYO key hash, account ID), which is useful beyond annotations.

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

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

Description is concise (4 sentences) and front-loaded with purpose. Every sentence adds value with no redundancy.

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

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

For a simple tool with one optional param and no output schema, description covers retrieval, listing, scope, and pairing with siblings. No gaps evident.

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

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

Schema covers the single parameter fully. Description adds behavioral semantics: omitting key lists all, providing key retrieves value, which enhances 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?

Description clearly states it retrieves values saved via remember or lists all keys. Verb+resource is explicit, and it distinguishes from sibling tools like 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 describes when to use (look up context stored earlier) and how (omit key to list all). Mentions pairing with remember and forget, providing clear guidance on 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 readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it fans out to multiple sources (SEC EDGAR, GDELT, USPTO) in parallel, explains return structure (structured changes + count + URIs), and clarifies that it's non-destructive. This goes beyond what annotations provide.

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

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

The description is two sentences, front-loading the core purpose and usage triggers. Every sentence adds value: first sentence states purpose and examples, second explains fan-out behavior, parameter details, and return format. No wasted words.

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

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

Given three parameters and no output schema, the description provides sufficient context: it explains all parameters with examples, describes the multi-source fan-out behavior, and states what the response contains (structured changes, total_changes count, citation URIs). For a monitoring tool, this is 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 description coverage is 100%, so baseline is 3. The description adds extra meaning beyond the schema: it explains that 'since' accepts ISO dates or relative shorthand (with examples), 'value' can be ticker or CIK, and 'type' is currently limited to company. This additional 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's purpose: finding recent changes about a company. It provides concrete example queries ('what's happening with X?', 'any updates on Y?') that help an agent understand when to invoke it. It also distinguishes from sibling tools like entity_profile by focusing on recency.

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

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

The description gives explicit usage examples and context ('Use when a user asks...'). It does not explicitly state when not to use it, but the examples cover typical use cases. It also notes monitoring scenarios, which is helpful 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?

Annotations provide readOnlyHint=false (confirming mutation) and no destructive hint. The description adds behavioral details beyond annotations: key-value pairing scoped by identifier, persistence differences for authenticated vs anonymous users (24-hour retention). This adds useful context without contradicting annotations.

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

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

The description is concise, with the main purpose front-loaded. It covers usage guidance and behavioral notes efficiently. A minor improvement could be tightening the phrasing, but overall it is well-structured and 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 (2 required parameters, no output schema), the description fully covers when and how to use it. It includes context about persistence and scoping, and references siblings for the full workflow. No gaps are apparent.

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

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

Schema coverage is 100% with descriptions for both 'key' and 'value' parameters. The description does not add additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate as the schema carries the full burden.

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 or sessions. It uses specific verbs ('Save data') and resources ('the agent will need to reuse later'), and distinguishes from siblings like 'recall' and 'forget' by mentioning them as complementary tools.

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

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

The description provides explicit guidance on when to use the tool ('when you discover something worth carrying forward') and mentions alternatives ('Pair with recall to retrieve later, forget to delete'), making it clear when this tool is appropriate versus its siblings.

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

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

Annotations already indicate safe read (readOnlyHint=true, destructiveHint=false). The description adds that the tool returns IDs plus citation URIs and explains the ID systems, providing context beyond annotations. However, it does not explicitly state behavior on ambiguous queries or empty results.

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 front-loaded with purpose and examples. No redundant information. Each sentence adds value, making it efficient and easy to parse.

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

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

Given the complexity (lookup tool with multiple ID types) and absence of output schema, the description adequately explains the output (IDs + citation URIs) and the supported input formats. It could mention error handling or multiple-match behavior, but overall it is complete enough for an agent to use correctly.

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

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

Schema description coverage is 100%, with each parameter having a clear description in the schema. The main description recaps input types and examples, but does not add substantial new meaning beyond what the schema already provides. The value parameter's flexibility is noted, but no deeper semantics are introduced.

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

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

The description clearly states the tool's purpose: looking up canonical identifiers for companies or drugs, with specific ID systems (CIK, ticker, RxCUI, LEI). Examples and usage context differentiate it from sibling tools, establishing a clear verb+resource+scope.

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 tells when to use this tool (when an official identifier is needed) and provides a usage order ('Use this BEFORE calling other tools'). It does not name alternative tools but implies they exist by stating it replaces 2-3 lookup calls.

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

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

The description adds no behavioral context beyond what the annotations already declare (readOnlyHint=true, openWorldHint=true, destructiveHint=false). It does not explain what 'snippet' means in terms of result completeness, pagination, or any limitations. With annotations covering safety, the description could still add value but does not.

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 that conveys the core purpose without extraneous words. It is front-loaded 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 absence of an output schema (0% coverage, no output schema), the description should explain what the returned JSON snippet contains (e.g., definitions, part of speech, examples). The vague phrase 'dictionary snippet' leaves much unspecified, making the tool incomplete for an agent to understand the return format.

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

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

The schema has 0% description coverage for the single required parameter 'query', but the description implies that the query should be a German word, adding semantic meaning. This compensates somewhat for the missing schema descriptions, though it remains brief.

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 that the tool returns a 'JSON dictionary snippet for a German word,' which clearly indicates that given a word query, it produces a dictionary entry. This distinguishes it from sibling tools like 'kwic' (keyword in context) and 'lemma' (lemma lookup), though 'snippet' is somewhat vague and could specify the exact content (e.g., definition, translation).

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

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

No guidance is provided on when to use this tool versus alternatives. For example, it does not clarify when to use 'snippet' over 'kwic' or 'corpus_concordance' for word lookups, nor does it mention prerequisites or context for optimal use.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true. The description adds substantial behavioral context: returns verdict, extracted structured form, actual value with citation, percent delta, and replaces multiple sequential calls. 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 concise (5 sentences) and well-structured. First sentence states purpose, second gives usage cues, third defines scope, fourth lists returns, fifth notes efficiency. Every sentence adds value without redundancy.

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

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

Given the tool has one parameter, clear annotations, and no output schema, the description covers purpose, usage, scope, return fields, and value proposition. It is 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 coverage is 100% with one parameter 'claim' already well-described in schema. Description adds no extra param detail beyond the schema, but baseline is 3 when schema covers fully.

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

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

The description clearly states that the tool fact-checks natural-language claims against authoritative sources, specifically for company-financial claims. It uses specific verbs like 'fact-check, verify, validate, confirm/refute' and distinct resource 'authoritative sources'. Among siblings like bet_research or compare_entities, it is clearly 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?

The description explicitly says when to use it: 'when an agent needs to check whether something a user said is true' with example queries. It also defines the scope (company-financial claims for US public companies). It does not explicitly state when not to use, but the scope acts as a reasonable exclusion.

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