Ebi Ols

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: it routes questions to 1,423+ tools across 392+ sources, returns structured answers with pipeworx:// citation URIs, and is non-destructive. This goes beyond the annotations by explaining the breadth of data sources and the citation format, earning a 4.

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 consists of two dense sentences with no unnecessary words. It front-loads the key directive 'PREFER OVER WEB SEARCH' and immediately follows with specific use cases and examples. Every sentence earns its place, making it highly efficient and readable.

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 only one parameter and no output schema, the description is remarkably complete. It explains the tool's purpose, scope (1,423+ tools, 392+ sources), expected behavior (routing, citation URIs), and provides concrete examples. For a tool of this complexity, the description leaves no critical gaps for an AI agent to understand when and how to use it.

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 one parameter 'question' described as 'Your question or request in natural language', providing 100% coverage. The description does not add new details about the parameter itself but explains how the question is processed (routed to tools, fills arguments). This is useful context but does not enhance the parameter's semantic meaning beyond the schema; hence baseline 3.

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

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

The description clearly states that the tool answers factual questions by routing to authoritative data sources and returning structured answers with stable citation URIs. It distinguishes itself from siblings like 'search' by emphasizing its preference over web search for specific domains (e.g., SEC filings, FDA data). The verb 'ask' and resource 'pipeworx' are well-defined with concrete examples.

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

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

The description explicitly lists when to use the tool (for factual questions about real-world entities, events, numbers) and provides examples. It strongly suggests preferring this over web search but does not explicitly name sibling tools that should be used for other types of queries (e.g., 'search' or 'entity_profile'). While the context is clear, the lack of explicit exclusions or alternative tool names prevents 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 indicate read-only and non-destructive behavior; the description adds valuable context on data sources (SEC EDGAR/XBRL, FAERS) and return format (paired data + citation URIs), enriching understanding 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 concise and front-loaded, with each sentence serving a purpose: stating purpose, usage triggers, behavior per type, and output. No unnecessary information.

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

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

Despite no output schema, the description fully covers what is returned (paired data, citation URIs) and data sources for each type. It is complete for a tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds examples for values (tickers like AAPL, drug names like ozempic) and clarifies the distinction between company and drug types, adding 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 compares 2-5 companies or drugs side by side, using specific verbs like 'compare' and 'pulls'. It distinguishes itself from sibling tools by focusing on multi-entity comparisons, which no other sibling explicitly does.

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 cues are provided (e.g., 'compare X and Y', 'X vs Y'), along with examples of when to use each type. It does not list alternatives or exclusions, but the context is clear enough for correct selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds that it returns tool names and descriptions, which is useful but not critical. No contradictions. The description adds modest behavioral context beyond the annotations.

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

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

The description is a single paragraph that is dense with information: purpose, usage guidance, examples. It is not overly verbose, and front-loads the purpose. Could be slightly more structured (e.g., bullet points for domains), but it is efficient and clear.

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

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

Given no output schema, the description explains the return format (top-N most relevant tools with names and descriptions). It covers when to call it (first) and what it searches across. It does not detail additional return fields like tool IDs or schemas, but for a discovery tool this is likely sufficient. The description is complete enough for an agent to use it effectively.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by providing concrete examples for the 'query' parameter (e.g., 'analyze housing market trends'), which helps the agent formulate effective queries. The 'limit' parameter is already well-defined in the schema. Overall, the description supplements the schema effectively.

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 find tools by describing data or task. It lists numerous specific domains (SEC filings, financials, FDA drugs, etc.) and explicitly states it returns the top-N most relevant tools. This distinguishes it from sibling tools like 'search' or 'resolve_entity,' which have different purposes.

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: 'Call this FIRST when you have many tools available and want to see the option set.' This tells the agent when to use it. It lacks explicit when-not or alternatives, but the 'first' directive is strong. A minor gap is no mention of when to skip this tool (e.g., if you already know the specific 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 indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: returns specific data types (SEC filings, financials, patents, news, LEI) with pipeworx:// citation URIs, and notes the type limitation to 'company' only.

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

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

The description is a single paragraph that packs substantial information, front-loading the purpose. It is efficient but could benefit from slight structural separation for readability (e.g., bullet points for returned data types).

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 high tool complexity (aggregates multiple sources), the description fully covers return content, input constraints, and citation format. It leaves no critical gaps for an AI agent.

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

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

Schema coverage is 100%, but the description adds critical meaning: value can be ticker or CIK, names require resolve_entity. The type parameter is documented as only 'company' supported, with future plans mentioned.

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 'Get everything about a company in one call' and lists concrete example queries. It distinguishes itself from siblings by noting it replaces 10+ pack tools across multiple sources.

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

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

The description provides explicit when-to-use scenarios (user asks about a company) and what not to do (use resolve_entity first if only have name). It also specifies accepted input formats (ticker or zero-padded CIK).

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 signal destructiveHint=true and readOnlyHint=false. The description confirms deletion but adds no behavioral details beyond what annotations provide. No contradictions.

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

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

Two sentences deliver purpose and usage guidance with zero wasted words. Front-loaded with the core action and immediately followed by relevant context.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose and usage adequately. It does not mention irreversibility, but destructiveHint implies it. Overall sufficient.

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

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

Schema coverage is 100% with one required parameter 'key' described as 'Memory key to delete'. The description does not add additional meaning beyond what the schema already provides, meeting the 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 'Delete a previously stored memory by key,' using a specific verb and resource. It distinguishes itself from sibling tools 'remember' and 'recall' by being the deletion counterpart.

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

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

Provides explicit when-to-use scenarios: 'when context is stale, the task is done, or you want to clear sensitive data.' Also recommends pairing with 'remember' and 'recall'. Lacks explicit when-not-to-use, but the guidance is clear and helpful.

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, openWorldHint, and destructiveHint. The description adds no further behavioral details (e.g., return format, caching).

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose and parameter usage efficiently.

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

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

For a simple, read-only tool with one parameter, the description is nearly complete. However, lacking an output schema or mention of return fields, it leaves some ambiguity about what metadata is provided.

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% coverage (no description for the 'id' parameter). The description compensates by providing example ontology IDs ('efo', 'mondo', 'go'), clarifying the expected input format.

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 ontology metadata by ID and provides concrete examples ('efo', 'mondo', 'go'). This differentiates it from sibling tools like list_ontologies (lists all) or get_term (gets a term).

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 does not explicitly state when to use this tool vs. alternatives like list_ontologies or get_term. The usage context (to get metadata for a known ontology ID) is implied but not elaborated.

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 no further behavioral details (e.g., return format). Given rich annotations, the description's minimal addition is acceptable but not extra helpful.

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, clear sentence. It is front-loaded with the purpose and efficiently conveys essential usage constraints. No wasted words, though a bit more structure could improve readability.

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

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

No output schema exists, and the description only says 'Term details' without specifying what fields are returned. For completeness, it should describe the response structure or link to documentation, especially given sibling tools that return different data.

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 2 of 4 parameters (50%). The description adds crucial semantics: mutual exclusivity among iri, short_form, obo_id, and the requirement of ontology for short_form/obo_id. This compensates for missing schema descriptions and clarifies usage 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 states 'Term details.' which clearly indicates the tool retrieves information about a term. It mentions three identifier options (iri, short_form, obo_id), distinguishing it from sibling tools like term_ancestors or term_children, though the precise scope of 'details' is vague.

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

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

It provides usage guidance on parameter selection ('Pass either iri, short_form, or obo_id') and notes the dependency on ontology for some identifiers. However, it does not compare with sibling tools (e.g., when to use this vs term_ancestors) or give context for ontology parameter.

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

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

Annotations already provide readOnlyHint, openWorldHint, and destructiveHint. The description adds 'paginated', which is a behavioral trait beyond the annotations, but not much else.

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

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

The description is a single, front-loaded sentence with no wasted words. Every part is necessary and informative.

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

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

For a simple list tool with pagination, the description sufficiently conveys the functionality. It could mention what is returned (e.g., ontology names or objects), but given the schema coverage and annotations, it is largely 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 descriptions for page and size. The description does not add additional meaning 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 action ('List'), the resource ('loaded ontologies'), and an important detail ('paginated'). It distinguishes itself from the sibling 'get_ontology' which is singular.

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 explicit guidance on when to use this tool versus alternatives (e.g., get_ontology, search). The context is simple, but the description does not help the agent decide when to use list_ontologies.

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 provided, and the description adds valuable behavioral details: rate-limited to 5 per identifier per day, free, doesn't count against tool-call quota, and that feedback is read daily and affects roadmap. No contradiction with annotations.

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

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

The description is concise, well-structured, and front-loaded with the purpose. Every sentence adds necessary information without redundancy. It is easy to scan and understand.

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 (3 parameters, no output schema), the description covers all aspects: when to use, what to include, side effects (rate limits, roadmap influence). No missing elements.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by giving concrete examples for the 'type' enum and encouraging specificity for 'message' (1-2 sentences typical, 2000 chars max). It does not replicate the schema but provides helpful usage context.

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

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

The description clearly states the tool is for providing feedback to the Pipeworx team, specifying categories (bug, feature, data_gap, praise) and distinguishing it from sibling tools (none of which are for feedback). The purpose is explicit and unambiguous.

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

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

The description explicitly states when to use the tool ('Use when...') for specific scenarios (bug, feature/data_gap, praise) and what not to do ('don't paste the end-user's prompt'). It also notes rate limits and quota implications, providing complete guidance.

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

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

Annotations already declare readOnlyHint as true and destructiveHint as false. The description adds scoping details (anonymous IP, BYO key hash, account ID) and mentions pairing with remember/forget, enhancing transparency 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?

Three sentences, each serving a purpose: main action, use cases, and scoping. Front-loaded with the primary function. No unnecessary words.

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

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

For a simple tool with one optional parameter, the description fully explains both retrieval and listing modes, scoping, and relationship to siblings. No output schema required given the simplicity.

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

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

The input schema covers the single parameter well with 100% description coverage. The description adds valuable nuance: omitting the key lists all keys, which is not explicit 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 uses specific verbs 'retrieve' and 'list' and clearly defines the resource as saved values or keys. It distinguishes from sibling tools 'remember' and 'forget' by stating it retrieves or lists, unlike saving or deleting.

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 concrete examples of when to use (look up target ticker, address, research notes) and mentions omitting the key to list all. However, it does not explicitly state when not to use or list alternatives beyond the sibling pair.

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

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

Annotations already indicate readOnly and non-destructive behavior. The description adds significant behavioral context: it fans out in parallel to three sources, returns structured changes with a count and citation URIs, and explains the 'since' parameter format. 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 concise yet comprehensive. It fronts the purpose, provides usage examples, explains the fan-out, and details parameters—all in a few sentences. No extraneous 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?

Despite lacking an output schema, the description clearly states what is returned (structured changes, total_changes count, citation URIs). It covers all essential aspects: purpose, when to use, parameters, data sources, and output format. Complete for the tool's complexity.

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

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

Schema coverage is 100% with descriptions for all parameters. The description goes beyond by explaining the 'since' parameter accepts ISO dates or relative shorthand (with examples and recommendation), and clarifies that 'value' can be a ticker or CIK. This adds practical guidance.

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

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

Clearly states the tool's purpose: retrieving recent changes for a company. Provides specific verb and resource ('what's new with a company') and distinguishes from siblings by naming the data sources (SEC EDGAR, GDELT, USPTO). Examples of user queries make it unmistakable.

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 example queries that signal when to use the tool. However, it does not mention when not to use it or suggest alternative sibling tools (e.g., entity_profile for static info, search for general queries). Thus, it is clear on context but lacks exclusions.

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 and destructiveHint=false. The description adds valuable behavioral context: key-value pair scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous sessions. No contradictions.

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

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

Four sentences, front-loaded with purpose and usage guidance. 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 save tool, the description covers purpose, when to use, scoping, persistence details, and pairing with siblings. No output schema needed, and the description is self-sufficient.

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

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

Input schema has 100% coverage with descriptions for key and value. The description adds meaning beyond schema by explaining scoping ('by your identifier') and providing usage examples like 'subject_property' and 'target_ticker'. This context helps the agent understand the intended parameter use.

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, using specific verbs ('Save') and resource ('data the agent will need to reuse later'). It distinguishes from siblings like 'recall' and 'forget' by explaining the persist/retrieve/delete lifecycle.

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 the tool ('when you discover something worth carrying forward') and mentions pairing with recall and forget. However, it does not explicitly state when NOT to use it or list alternatives beyond the sibling tools.

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

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

Annotations (readOnlyHint, openWorldHint, destructiveHint) already convey safety. The description adds behavioral context beyond annotations: it returns 'IDs plus pipeworx:// citation URIs' and mentions replacing 2–3 lookup calls. This is valuable but could further clarify that the tool does not modify any state.

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 action ('Look up the canonical/official identifier') and each subsequent sentence adds essential context (ID types, examples, usage order, efficiency claim). No redundant or vague language; 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 the tool's moderate complexity (2 params, no output schema), the description fully explains what the tool returns (canonical IDs, URIs) and provides examples for both entity types. It covers all necessary context for an AI agent to decide when and how to invoke 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?

Schema coverage is 100%, so baseline is 3. The description adds significant meaning by providing concrete examples for each parameter: for 'value' it says 'For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., 'ozempic', 'metformin').' This clarifies acceptable inputs beyond the schema's simple description.

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

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

The description clearly specifies that the tool resolves entity names to canonical identifiers (CIK, ticker, RxCUI, LEI) with concrete examples like 'Apple' → AAPL / CIK 0000320193 and 'Ozempic' → RxCUI 1991306. It distinguishes itself by stating it replaces 2-3 lookup calls and is positioned relative to sibling tools that require these identifiers.

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

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

The description explicitly states when to use: 'Use when a user mentions a name and you need the CIK...' and provides sequential guidance: 'Use this BEFORE calling other tools that need official identifiers.' This gives clear context for invocation without ambiguity.

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 agent knows it is a safe read operation. The description adds behavioral context by specifying 'across all ontologies (or one),' which clarifies the scope of the search beyond the default parameters.

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, clear sentence that front-loads the purpose. Every word is necessary and earns its place, with no filler or redundancy.

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

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

Given the tool has 5 parameters and no output schema, the description is somewhat incomplete. It does not explain return value format, sorting, or result structure. The schema covers param descriptions well, but the description could provide more context on usage 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?

With schema coverage at 80% (4 out of 5 parameters have descriptions), the description adds minimal value beyond the schema. It reinforces the 'ontology' parameter but does not provide additional meaning for other parameters. Baseline of 3 is appropriate given high schema coverage.

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 'Full-text search across all ontologies (or one)' with a specific verb and resource. It effectively identifies the tool's primary function and distinguishes it from sibling tools like 'get_term' or 'resolve_entity' by indicating it performs a broad text 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?

The description implies usage for full-text searching across ontologies and provides the option to restrict to one, but it lacks explicit guidance on when to use this tool versus alternatives like 'term_ancestors' or 'resolve_entity.' No exclusions or context for when not to use 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?

Annotations already declare the tool as read-only and non-destructive. The description adds no additional behavioral context, such as performance implications, pagination, or handling of missing terms. 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 very short (four words) and front-loaded. It is concise, but arguably too brief to provide sufficient context. Every word is necessary, but the description lacks informational density.

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 two required parameters and no output schema, the description should at least explain parameters or return type. It fails to do so, leaving the agent without enough context 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?

With 0% schema description coverage, the description must compensate but does not. The two required parameters (iri and ontology) are not explained. The description 'ancestors of a term' implies usage of 'iri' but gives no details on format or 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 'Transitive ancestors of a term' clearly indicates the tool returns the ancestral chain of a given term. It distinguishes from sibling 'term_children' which returns descendants. However, it uses a noun phrase without an explicit verb, which slightly reduces clarity.

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?

There is no guidance on when to use this tool versus alternatives like 'term_children' or 'get_term'. No exclusions or conditions are mentioned, leaving the agent without contextual selection cues.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is clear. The description adds the constraint 'direct', which clarifies that only immediate children are returned, not all descendants. This is useful but minimal additional 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 short sentence, which is concise but under-specified. It lacks sufficient detail to be considered 'appropriately sized' for a tool with two parameters.

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 low complexity (2 params, no output schema), the description is incomplete. It does not mention return format, prerequisites, or any additional behavioral notes. The annotations and schema provide some structure, but the description leaves 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?

The input schema has two required parameters (iri, ontology) with 0% description coverage. The description does not explain what these parameters represent or how they should be used, failing to compensate for the lack of schema documentation.

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 'Direct children of a term,' which identifies the output as immediate child terms. However, it does not explicitly link to the ontology context or distinguish from sibling tools like 'term_ancestors' beyond the word 'children'.

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 such as 'term_ancestors', 'search', or 'entity_profile'. The agent is left to infer usage from the name and sibling list.

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: true, openWorldHint: true, destructiveHint: false) are consistent and the description adds significant context beyond them: it mentions the authoritative source (SEC EDGAR + XBRL), the verdict options, the structured output with citations and percent delta, and that it replaces multiple sequential calls. No contradiction with annotations.

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

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

Description is moderately long but every sentence adds value: purpose, usage, scope, output details, and benefit. It is front-loaded with the core purpose. Could be slightly more concise (e.g., combine the first two sentences), but no extraneous information.

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

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

For a tool with one parameter and no output schema, the description adequately explains input, output (verdict types, structured form, citation, percent delta), and scope (financial claims, US companies). It could be improved by mentioning what happens if the claim is not financial (unsupported or inconclusive) or noting edge cases, but overall it is fairly complete for an agent to understand usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema's parameter description: it reinforces that the claim is natural-language and provides examples. It does not add syntax, formatting details, or constraints beyond what the schema already states.

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 specific verbs (fact-check, verify, validate, confirm/refute) and clearly identifies the resource as natural-language factual claims, with explicit scope 'company-financial claims (revenue, net income, cash position for public US companies)'. It distinguishes itself from siblings by noting it replaces 4–6 sequential calls, which no other sibling does.

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 explicitly states when to use: 'Use when an agent needs to check whether something a user said is true' and provides example queries. It also notes the current scope (v1 supports only financial claims). However, it does not provide explicit when-not-to-use or alternatives, which would be helpful for an agent deciding between this and similar tools like search or entity_profile.

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