Openfda

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

Discloses key behavior: it picks the right tool, fills arguments, and returns results. Since no annotations are provided, the description carries the full burden. It doesn't mention limitations (e.g., potential inaccuracy, latency), but covers the core value well.

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?

Extremely concise: three sentences with front-loaded purpose, then examples. Every sentence adds value; no fluff.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete enough. It explains the tool's role relative to siblings and provides examples. Could mention output format, but not critical.

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 context that the parameter is a natural language question, but doesn't provide additional detail beyond the schema description.

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

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

Description clearly states the tool accepts plain English questions and returns answers from the best data source. It distinguishes itself by acting as an intelligent router, unlike sibling tools that are specialized (e.g., fda_drug_events).

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

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

Explicitly tells when to use this tool: when you have a natural language question and don't want to pick tools or learn schemas. Provides concrete examples. Implicitly indicates alternatives (sibling tools) are for direct access.

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

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

Annotations indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description aligns perfectly. It adds rich behavioral context: resolves the market, classifies bet type, fans out to appropriate packs, and returns a 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?

The description is front-loaded with the main purpose and is well-structured. It includes input types, process, output, use cases, and value proposition without significant redundancy. Could be slightly more concise, but each sentence serves a purpose.

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

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

Given no output schema, the description adequately explains the output ('evidence packet plus a simple market-vs-model comparison'). It also covers the internal fan-out logic and bet classification. The tool has only two parameters with high schema coverage, making the description complete.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds no additional information about the parameters beyond what the schema provides (e.g., it does not explicitly mention the 'depth' parameter). 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 core purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies inputs (slug, URL, or question text) and outputs (evidence packet plus market-vs-model comparison). The description distinguishes the tool from siblings by positioning it as a core demo product that avoids manual pack 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?

Explicit use cases are provided: 'Use for "should I bet on X?", "what does the data say about this Polymarket market?", or "is there edge in this bet?".' While it doesn't explicitly state when not to use or name alternatives, the context is clear and actionable.

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

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

No annotations are provided, so the description carries full burden. It mentions the output includes paired data and URIs but does not disclose any behavioral traits like authentication requirements, rate limits, or side effects. The return format is vague.

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

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

The description is concise (three sentences) and front-loads the main purpose. It could be more structured but effectively communicates the core functionality 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 absence of an output schema, the description provides a basic overview of returns but lacks detail on the exact structure of 'paired data' and error handling. It is adequate for a simple comparison tool but leaves some gaps for complex usage.

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

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

The input schema has 100% coverage with descriptions, but the description adds significant value by mapping 'company' type to financial metrics from SEC EDGAR and 'drug' type to adverse events, approvals, and trials. It also specifies value formats (tickers/CIKs for company, drug names for drug). This goes beyond the schema's basic type 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 function: comparing 2-5 entities side by side, with specific data attributes for each type (company/drug). It distinguishes itself from sibling tools by aggregating multiple data sources into one call, replacing 8-15 sequential calls.

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

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

The description implies when to use (for multi-entity comparison) and mentions efficiency gains over sequential calls. However, it does not explicitly state when not to use, such as for single entity queries or for data not covered by the specified types.

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

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

The description discloses that the tool returns the most relevant tools with names and descriptions, and that it uses natural language queries. With no annotations, this is sufficient behavioral context. It does not mention rate limits or side effects, but as a search tool, these are 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 concise: three sentences, each with clear value. The first states the core function, the second describes return value, and the third provides usage context. 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 the tool's simplicity (search with query and limit), the description is nearly complete. It covers purpose, usage, and return type. It does not mention the 'limit' parameter explicitly in the description, but the schema already handles that.

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 well-documented in the schema. The description adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: searching the Pipeworx tool catalog by describing a need. It specifies the action ('search'), resource ('tool catalog'), and distinguishes it from other tools by instructing to call it first when many tools are available.

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 usage guidance: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This tells the agent when to use this tool and implies it is not needed for small tool sets.

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 transparency burden. It explains the tool is a comprehensive query returning recent data and citation URIs, implying read-only behavior. It could mention that it is non-destructive, but the nature is clear. No contradictions.

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

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

Two sentences plus a brief type note, all essential. No fluff, key information front-loaded. Replaces verbose elaboration.

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 compensates by listing data sources and output URIs. It includes an exclusion note. Missing timeframe for 'recent' and possible error conditions, but sufficient for typical use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds little beyond the schema: it repeats 'type' support and value formats, but provides examples (e.g., AAPL). No new semantics beyond the existing parameter descriptions.

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

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

The description clearly states the tool's purpose: returning a full profile of an entity across Pipeworx packs in one call. It specifies supported type, data categories included (SEC, patents, news, LEI), and output format (pipeworx:// URIs). It distinguishes itself from siblings by noting it replaces 10-15 sequential calls and directs to usa_recipient_profile for federal contracts.

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

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

Explicitly tells when to use (as a single-call alternative to many) and when not (for federal contracts, use usa_recipient_profile). Parameter description for value advises using resolve_entity for names. This provides clear 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?

No annotations are provided, so the description must convey behavior. It correctly indicates a read/search operation and specifies the data source (Drugs@FDA). However, it does not disclose potential limitations (e.g., no pagination info, no mention of rate limits or required authentication). The description is clear but could add more behavioral context.

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

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

The description is a single sentence with 15 words, front-loading the core purpose and then listing search fields. Every word contributes meaning, 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?

The tool has 2 parameters (both documented), no output schema, and no annotations. The description provides the essential purpose and searchable fields. However, it omits details like what the return format is (e.g., list of records, metadata), whether results are paginated, or any example usage. For a search tool, additional guidance on constructing queries would improve completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no further parameter details beyond what is in the schema; the query parameter examples are already provided in the schema description. The description does not elaborate on the limit parameter or add new 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 searches FDA drug approval records (Drugs@FDA) and specifies searchable fields: brand name, generic name, application number, or sponsor. The verb 'Search' combined with the resource 'FDA drug approval records' provides a specific and distinct purpose. It distinguishes itself from sibling tools like fda_drug_events or fda_drug_labels by targeting approvals specifically.

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 implicitly suggests usage for finding approved drugs but does not provide explicit guidance on when to use this tool versus alternatives like fda_drug_labels or fda_drug_events. There is no mention of when not to use it or scenarios where a different tool would be more appropriate.

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 implies read-only behavior by stating 'Search' and does not contradict any annotations (none provided). It discloses the data source (FAERS) and the ability to filter by drug name, reaction, etc., which is sufficient given the absence of annotations. No destructive or complex behaviors are 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 two sentences, both informative. The first sentence states purpose, the second adds usage details. No wasted words, and the key information is front-loaded.

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

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

Given the schema coverage is 100% and no output schema exists, the description provides enough context for the agent to understand the tool's functionality. It could optionally mention return format or pagination limits, but the schema already covers skip and limit constraints (1-100). The absence of output schema is compensated by the schema description.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds example query strings, which clarifies the 'query' parameter format beyond the schema description. However, 'skip' and 'limit' are standard pagination parameters with adequate schema descriptions, so no additional value needed.

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 queries the FDA Adverse Event Reporting System for drug adverse event reports, using a specific verb 'Search' and a well-defined resource 'FAERS'. It distinguishes itself from sibling tools like 'fda_drug_approvals' or 'fda_drug_labels' by focusing on adverse events.

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

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

The description mentions support for OpenFDA search syntax and gives examples, but does not explicitly state when not to use this tool or compare it to alternatives like 'fda_event_counts'. However, the context signals show clear sibling differentiation, and the examples provide practical usage guidance.

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

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

Annotations are empty, so the description carries the full burden. It describes the tool as a search returning label sections, which is clear and non-misleading. However, it does not disclose pagination behavior or any rate limits, which would be helpful for an FDA API.

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 at two sentences, with the first sentence front-loading the core purpose. It avoids unnecessary detail, but could be slightly more structured (e.g., listing return sections more clearly).

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 provides adequate context about return content (label sections). The tool is simple with two parameters, and the description covers what the tool does and what it returns. No major gaps.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond what the schema provides (query and limit are already explained). No additional semantics are provided.

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

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

The description states a specific verb ('Search') and resource ('FDA drug labeling (Structured Product Labeling)'), and lists typical returned sections (indications, warnings, dosage, contraindications). This clearly distinguishes it from siblings like fda_drug_approvals or fda_drug_events.

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 use when FDA drug label data is needed, but does not explicitly state when to use this tool versus alternatives like fda_drug_approvals or fda_drug_events. No exclusion criteria are given.

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, so the description carries the full burden. It describes the action (search) and input types, but does not disclose behavioral traits such as whether it is read-only, rate limits, or potential impacts. The description is consistent with a read operation but lacks explicit safety 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 concise, with two sentences that efficiently state the purpose and capabilities. It front-loads the key action and provides specific examples in the parameter descriptions, making it easy to scan.

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

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

Given the tool's moderate complexity (2 parameters, no output schema), the description covers the core functionality. However, it does not describe the output format or any pagination behavior, which would be helpful for an agent to use the results. The context signals show no output schema, so the description could have elaborated on return values.

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

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

Schema description coverage is 100% (both parameters are described). The description adds value by explaining the overall purpose and providing examples for the query parameter, which clarifies the expected format beyond the schema. No parameters are left undocumented.

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 searches FDA drug recall and enforcement actions, specifying it finds recalls by drug name, classification level, or reason. It distinguishes the tool from siblings like fda_drug_approvals and fda_drug_events, which handle different FDA data sets.

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 a clear context for when to use this tool (searching drug recalls) but does not explicitly contrast with sibling tools or provide guidance on when not to use it. The examples in parameter descriptions give some usage hints but no explicit exclusion criteria.

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, so the description carries the full burden. It discloses the aggregation behavior and hints at return format (counts), but does not explicitly state that results are grouped counts, nor mention pagination, limits, or safety (read-only). It is adequate but could be more precise.

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 that are front-loaded with purpose and include powerful examples. No wasted words; every sentence adds value.

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

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

Given that there is no output schema and no annotations, the description is reasonably complete for a counting tool. It explains what it does, provides usage guidance, and gives concrete parameter examples. Could mention that results are limited (e.g., top N) or return format, but overall adequate.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds value by providing concrete examples for count_field (e.g., 'patient.reaction.reactionmeddrapt.exact'), which helps the agent understand valid fields. 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 uses specific verbs ('Count', 'grouped') and resource ('adverse events', 'field') and provides concrete use cases ('find the top adverse reactions for a drug, or see event timelines'). It clearly distinguishes from siblings like fda_drug_events (which likely returns raw events) by specifying aggregation/counting behavior.

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

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

The description implies usage for signal detection and provides examples of when to use it ('find top adverse reactions', 'see event timelines'). It does not explicitly say when not to use it or mention alternatives, but the sibling tools are distinct enough that confusion is unlikely.

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 provided, so description carries full burden. It states the destructive action 'delete' clearly but does not disclose details like irreversibility or confirmation requirements.

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 a single sentence of five words, perfectly concise. No fluff, but it could be slightly more informative without harming conciseness.

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

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

Given the simple tool with 1 param and no output schema, the description is nearly complete. However, it lacks behavioral context (e.g., what happens if key doesn't exist) that would be helpful.

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 the parameter 'key' already described. The description adds no additional meaning beyond 'by key', but baseline 3 is appropriate.

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

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

Description uses a specific verb 'Delete' and resource 'stored memory by key', clearly distinguishing from siblings like 'recall' and 'remember'.

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 implies usage (deleting a memory by key) but does not provide guidance on when to use this vs. alternatives like 'recall' or 'remember', nor any conditions or side effects.

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 provided, so description bears full burden. It discloses rate-limiting (5 messages per day) and advises against including user prompts. This is sufficient behavioral context for a feedback tool.

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

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

Three concise sentences front-load purpose, provide examples, and add rate-limit info. No wasted words.

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

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

Given no output schema and no annotations, the description covers purpose, usage guidelines, rate limits, and content rules. Sufficient for an agent to use correctly, though more details on error handling or response format would improve.

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 schema already documents all parameters. Description adds some context (e.g., 'describe what you tried' for message) but does not add significant new meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb (Send) and resource (feedback), and lists specific use cases: bug reports, feature requests, missing data, or praise. It distinguishes itself from sibling tools like ask_pipeworx or discover_tools by being a feedback mechanism.

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 (bug reports, feature requests, missing data, praise) and content rules (describe what you tried, do not include end-user prompt). It lacks explicit 'when not to use' but the purpose is narrow 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?

Description discloses detailed behavior: walks child markets, extracts dates/thresholds, sorts, and reports violations. Adds information beyond annotations (which only declare readOnly, openWorld, non-destructive). No contradiction.

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

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

Description is well-structured: starts with purpose, explains the concept, then usage, then output. Every sentence adds value. No redundancy.

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

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

For a simple tool with one parameter and no output schema, the description is complete: it explains the input, the processing logic, and the output format. Annotations provide additional safety signals. Agent can 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 already provides description for the single parameter 'event' with 100% coverage. Description repeats the input format but adds context about how the parameter is used (walking child markets). Baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

Description clearly states the tool finds arbitrage opportunities via monotonicity violations. Uses specific verb 'find' and resource 'arbitrage opportunities within a Polymarket event'. Distinguishes from sibling tools like 'polymarket_edges' by its unique function.

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?

Explains when to use: when monitoring Polymarket events for arbitrage. Provides clear context on the logic and input format (event slug or URL). Does not explicitly specify when not to use or mention alternatives, but the context is sufficient.

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

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

Annotations (readOnlyHint, openWorldHint) indicate safe, read-only behavior. The description adds rich behavioral details: it scans top markets, groups by asset, fetches price history once, computes probability, ranks by edge. It explains the underlying model (lognormal from FRED + coinpaprika). No contradiction.

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

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

The description is informative but not overly long. It front-loads the core action and follows with model details and intended use. Every sentence adds value, though some model background could be condensed for brevity.

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

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

Given the tool's complexity (multiple steps, external data sources, ranking algorithm), the description covers the essential workflow. It lacks an explicit output schema but mentions return structure (top N, edge magnitude, trade direction). Sufficient for understanding without being exhaustive.

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

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

The input schema has 100% description coverage, and the description reinforces the parameters' roles: limit (top N), window (volume window), min_edge_pp (minimum edge). It adds no new syntax but provides conceptual context, justifying above baseline.

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

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

The description clearly states the tool's purpose: scanning high-volume Polymarket markets and returning those where Pipeworx data disagrees most with market price. It provides specifics on the model (lognormal from FRED + coinpaprika) and output (top N by edge magnitude with trade direction). This distinguishes it from siblings like polymarket_arbitrage and ask_pipeworx.

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

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

The description explicitly states the intended use case: 'what should I bet on today' for discovering opportunities. It does not mention when to avoid it or alternatives, but the context is clear enough for an agent. A more explicit contrast with sibling tools would improve this score.

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, so the description carries full burden. It discloses that omitting the key lists all memories, but doesn't mention side effects, whether it's read-only, or if memories persist across sessions.

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 with no wasted words. It front-loads the action and provides a succinct purpose statement.

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 (single optional param, no output schema), the description covers the essential behavior. It could mention that output is a string or list, but that's implied.

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 optional parameter 'key'. The description adds meaning by explaining that omitting the key lists all memories, which is not clear from the schema alone.

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

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

The description clearly states the tool retrieves a memory by key or lists all memories, with the verb 'retrieve' and resource 'memory'. It also distinguishes itself from 'remember' and 'forget' by its retrieval focus.

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

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

The description explicitly says to use this for retrieving context saved earlier, which gives usage context. However, it doesn't explicitly contrast with sibling tools like 'remember' or 'forget' or state when not to use it.

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

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

With no annotations, the description carries full burden. It details the parallel fan-out to SEC EDGAR, GDELT, USPTO, and the return structure (structured changes, total_changes, URIs). It does not explicitly state idempotency or safety, but the context implies a read-only operation.

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

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

The description is concise at 4 sentences, with the key purpose upfront. Every sentence provides unique value: purpose, fan-out details, parameter guidance, and return structure. No wasted words.

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

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

Given no output schema, the description explains the return structure. It covers entity type, since options, value format, and parallel execution. Minor omissions: no mention of error handling or rate limits, but overall sufficient for typical use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: examples for 'since' (ISO dates and relative), suggestion '30d' for typical monitoring, and explanation of 'value' as ticker or CIK. This enhances usability beyond the schema.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time.' It specifically describes fanning out to multiple sources for type='company', which distinguishes it from siblings 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 says 'Use for "brief me on what happened with X" or change-monitoring workflows,' providing clear use cases. However, it does not mention when not to use it or suggest alternative tools for other needs.

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

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

No annotations provided, so the description must cover behavior. It does well by explaining memory persistence (authenticated vs anonymous) and storage semantics (key-value). It does not mention any limits (e.g., max size, number of pairs) but covers the most critical behavioral trait.

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

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

The description is three sentences, each providing essential information: what it does, when to use it, and behavioral notes. No superfluous content.

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

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

Given the simplicity of the tool (2 required string params, no output schema), the description is adequately complete. It covers purpose, usage, and persistence behavior. Minor missing details like size limits or overwrite behavior could enhance it, but not required for a straightforward memory store.

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 the schema already documents both parameters well. The description adds no additional parameter-specific information beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description explicitly states 'Store a key-value pair in your session memory', which is a clear verb+resource combination. It differentiates from siblings like 'recall' (retrieve) and 'forget' (delete) by focusing on storage.

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 clear usage context: 'Use this to save intermediate findings, user preferences, or context across tool calls.' It also notes the persistence difference between authenticated and anonymous sessions, but 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?

With no annotations, the description carries full burden. It reveals expected outputs (ticker, CIK, name, URIs) and input examples, but does not mention safety (read-only), error behavior, or rate limits. For a resolver, this is partially transparent but could be more explicit.

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 following with details on input, output, and value. No wasted words; every sentence earns its place.

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

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

Given a simple tool with 2 parameters, 100% schema coverage, and no output schema, the description covers inputs, outputs, and expected behavior comprehensively. It could mention the format of URIs or error handling, but the current level is sufficient for typical use.

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

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

Schema coverage is 100% (both parameters described), and the description adds valuable context: examples of valid values, clarification that v1 only supports company, and the purpose of each parameter. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool resolves an entity (company) to canonical IDs, specifies accepted input formats (ticker, CIK, name), and lists outputs. It distinguishes itself from sibling tools by focusing on entity resolution across Pipeworx data sources, replacing multiple lookup calls.

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

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

The description implies when to use (for efficient single-call entity resolution) but does not explicitly state when not to use or provide alternatives. The sibling tools are mostly unrelated, so the guidance is adequate but lacks explicit exclusion criteria.

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, so the description carries the full burden. It describes the return values (verdict, extracted form, actual value with citation, percent delta) but does not disclose additional behavioral traits like whether it is read-only, authentication needs, rate limits, or error conditions. The transparency is adequate for a fact-checking tool but could add more context.

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

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

The description is two sentences, each earning its place. The first sentence states the core purpose; the second sentence provides details on supported claims, sources, return values, and efficiency benefits. It is well-structured, front-loaded, and concise without 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?

With one required parameter, no output schema, and low complexity, the description is quite complete. It covers what the tool does, supported claim types, return values, and efficiency improvement over alternatives. It does not mention any constraints like prerequisites (e.g., internet access) but those are implicit. Overall, it provides sufficient context for an agent to use the tool correctly.

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

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

The only parameter 'claim' has a clear description with examples in both the schema and the main description. Schema coverage is 100%. The description adds value by providing usage examples and clarifying the expected format, beyond what the schema alone provides.

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

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

The description clearly states the tool's purpose: fact-check a natural-language claim against authoritative sources. It specifies the domain (company-financial claims for US public companies) and sources (SEC EDGAR + XBRL). It lists the verdict types and return value, and distinguishes from siblings by noting it replaces sequential agent calls.

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 supported claim types (company-financial, revenue/net income/cash for public US companies) and implies when not to use (other claims). It mentions efficiency gains over sequential calls, but does not explicitly list alternatives or exclusions beyond the supported domain.

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