Europepmc

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

Annotations already indicate read-only behavior (readOnlyHint=true). The description adds that the tool returns only title+abstract and is faster than get_article, providing useful behavioral context without contradiction.

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

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

The description is a single, concise sentence that efficiently communicates the tool's purpose and key differentiator without any superfluous 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?

While the description covers the basic purpose and differentiation, it lacks details on the return format or structure (e.g., how title and abstract are returned), and does not mention error conditions or limits. Given no output schema, more context would be beneficial.

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 0% description coverage, and the tool description does not explain the meaning or expected values of the 'source' and 'id' parameters. The agent has no guidance on what these parameters represent beyond the schema structure.

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 that the tool returns the title and abstract for one article, and distinguishes itself from the sibling tool 'get_article' by noting it is faster.

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

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

The description provides clear usage context by comparing with 'get_article', implying this tool is preferred when only the title and abstract are needed and speed is a factor, though it does not explicitly 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?

Annotations declare readOnlyHint=true, which the description aligns with by describing a read-only operation. The description adds valuable behavioral context: it routes questions to the appropriate tool among 1,423+, fills arguments, and returns structured answers with stable pipeworx:// citation URIs. This goes beyond annotations to explain internal routing and output format.

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 efficiently conveys purpose, usage, and behavior. It's front-loaded with the key guidance. However, it could be slightly more structured (e.g., bullet points for examples) without losing conciseness. Still, every sentence adds value.

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

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

Given the tool's complexity (1,423+ tools, 392+ sources) and the absence of an output schema, the description covers the essential aspects: it explains the routing mechanism, confirmed behavior, and return format (structured answer with citation URIs). It doesn't detail error handling or latency, but for a question-answering tool, this is sufficient. A 5 would require mention of limitations or failure modes.

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% (one parameter 'question' fully described). The description adds examples and clarifies the scope of acceptable questions (factual, real-world entities, events, numbers), which enriches the schema definition. It doesn't repeat the schema but provides usage context, so it exceeds the baseline of 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 uses a specific verb ('ask') and a clear resource ('PipeWorx'), and explicitly lists 392+ verified sources and 1,423+ tools. It distinguishes itself from web search by stating 'PREFER OVER WEB SEARCH' and provides concrete examples of domains (SEC filings, FDA data, etc.). This unambiguously differentiates it from sibling tools like 'search' 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 includes explicit when-to-use guidance ('PREFER OVER WEB SEARCH'), a comprehensive list of query types ('what is', 'look up', 'find', etc.), and concrete examples (e.g., 'current US unemployment rate'). It also implies when not to use (e.g., for broad exploratory queries better suited to web search). This leaves no ambiguity about appropriate usage.

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

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

The description adds no behavioral traits beyond the 'readOnlyHint' annotation. It does not mention any side effects, permissions, or limitations.

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 6 words, which is concise. However, it is under-specified for a tool with 3 parameters, lacking necessary details.

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 3 parameters and no output schema, the description is incomplete. It does not clarify the roles of 'id' and 'source', the return format, or any pagination behavior beyond the schema's hint for 'pageSize'.

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 only 33% (only 'pageSize' has a description). The description does not explain the meaning of 'id' and 'source', which are required but undocumented. With low coverage, the description fails to compensate.

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

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

The description uses the verb 'list' and specifies the resource as 'articles citing one article', which clearly indicates the tool's purpose. However, it does not differentiate from the sibling tool 'references', which might have a similar 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?

No guidance on when to use this tool over alternatives like 'references' or 'get_article'. The description does not specify any context, prerequisites, or 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 indicate readOnlyHint=true. Description adds specific data sources (SEC EDGAR/XBRL, FAERS, FDA) and return format (paired data + citation URIs), surpassing annotation-only 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?

Concise, front-loaded with main purpose, and each sentence adds value. No wasted words.

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

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

Covers two modes, data sources, and return format. Lacks explicit mention of maxItems=5 constraint, but that is in schema. Good completeness for a comparison tool.

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

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

Schema coverage is 100%, so baseline is 3. Description reiterates schema-provided info but adds no new parameter-specific details beyond the schema descriptions.

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

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

Clear verb+resource: compare 2-5 companies/drugs. Distinguishes from sibling entity_profile by focusing on side-by-side comparison rather than single entity details.

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

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

Explicitly lists user intents ('compare X and Y', 'X vs Y', etc.) and states it replaces multiple sequential calls, providing clear guidance on when to use.

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

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

Annotations already set readOnlyHint=true, so the description's read-only nature is consistent. The description adds that it 'Returns the top-N most relevant tools with names + descriptions,' which is useful but not critical behavioral information. No additional traits like rate limits or auth needs are disclosed.

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

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

The description is moderately sized and front-loaded with the core purpose. It lists many example domains, which helps but could be slightly more concise. Overall, every sentence adds value without redundancy.

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

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

Given no output schema, the description appropriately explains that it returns the top-N most relevant tools with names and descriptions. Parameter descriptions are in the schema. The tool is simple, so this coverage is sufficient. No missing critical information.

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

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

Schema coverage is 100%, so the description does not add new meaning beyond the schema for the two parameters. The description lists examples for the query parameter (e.g., 'analyze housing market trends') but this is already implied by the schema's description. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description starts with 'Find tools by describing the data or task,' which is a specific verb+resource combination. It distinguishes from sibling tools like 'search' and 'get_article' by focusing on discovering available tools, not executing a specific data lookup.

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 'Use when you need to browse, search, look up, or discover what tools exist for:' followed by a comprehensive list of domains. It also advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' providing clear context and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, but description adds substantial behavioral context: lists returned data types (SEC filings, fundamentals, patents, news, LEI), mentions citation URIs, and specifies valid inputs (ticker or CIK). No contradictions.

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

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

Description is a single sentence but packs essential information front-loaded. While effective, it could be slightly more structured (e.g., bullet points) for easier scanning.

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

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

Given the tool's complexity (multiple data sources), the description covers all key return components even without an output schema. Minor omission: no mention of pagination or limits, but acceptable for a profile endpoint.

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

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

Schema has 100% description coverage, so baseline is 3. Description adds extra meaning: clarifies that 'type' currently only supports 'company', and for 'value' explains ticker/CIK format and fallback to resolve_entity for names. Slightly 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 starts with 'Get everything about a company in one call,' clearly stating the verb, resource, and scope. It differentiates from siblings like 'compare_entities' and 'resolve_entity' by focusing on aggregated company data.

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 specifies when to use (user asks 'tell me about X' etc.) and when not to (names not supported, must use resolve_entity instead). Names the alternative tool 'resolve_entity' directly.

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=false, consistent with 'Delete' action. The description adds context about appropriate usage but does not disclose error handling (e.g., behavior if key does not exist) or return value, leaving moderate gaps.

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 effectively convey purpose and usage guidelines with no redundancy. The description is front-loaded and every word 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 the tool's simplicity (one required parameter, no output schema), the description adequately covers when and why to use it, but omits return value or success/failure indicators.

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

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

Schema coverage is 100%, and the description does not add parameter information beyond the schema's 'Memory key to delete.' No extra semantics or constraints 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 clearly states 'Delete a previously stored memory by key,' combining a specific verb and resource. It also mentions pairing with siblings 'remember' and 'recall,' differentiating this tool as 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?

The description provides explicit use cases: 'when context is stale, the task is done, or you want to clear sensitive data.' It suggests pairing with remember/recall, implicitly indicating when not to use, but lacks a direct exclusion statement.

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

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

Annotations already provide readOnlyHint=true, so the description adds little behavioral insight beyond 'Full record'. It does not disclose the nature of the record, pagination, rate limits, or authentication needs. The description adds minimal value beyond the annotation.

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

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

The description is a single, well-structured sentence with a parenthetical list of source expansions. Every word is useful, and it is concise without being under-specified.

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 2-parameter lookup tool with no output schema, the description sufficiently communicates the input scope. However, it lacks details about the return format or content of the 'full record', which might be needed for an AI to fully understand the output. Given the low complexity, it is mostly 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%, so the baseline is 3. The description repeats the schema's parameter descriptions (e.g., 'PMID for MED') but adds no new meaning beyond confirming the pattern. It does not clarify edge cases or required formats.

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 the 'Full record for one article' identified by source and id, using a specific verb and resource. It distinguishes itself from sibling tools like search (multiple records) and abstract (part of article) by specifying it's for one article's full record.

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

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

The description lists valid source values (MED, PMC, PPR, CTX) and implies id corresponds to identifiers like PMID, providing enough context for an AI to decide when to use this tool. While it doesn't explicitly state when not to use or name alternatives, the context is sufficient for a typical agent.

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

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

Annotations only include readOnlyHint=false, so description carries burden. It discloses rate limits, quota impact (doesn't count), and that team reads digests daily. No contradiction with annotations, but could mention whether feedback is anonymous or other side effects.

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 paragraphs, front-loaded with purpose. Every sentence adds unique information (use cases, constraints, format). Could be slightly more streamlined but highly efficient for the content covered.

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

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

Given no output schema, description explains what happens (team gets feedback, affects roadmap). Covers when, what, how, and limitations. Fully adequate for a simple feedback tool; no gaps.

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

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

Schema coverage is 100%, so schema already documents params. Description adds value by explaining enum values in prose, providing message length guidance (1-2 sentences, 2000 chars), and advising use of context object. Nested object is explained.

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 starts with specific verb-noun structure 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes the tool's purpose from siblings by enumerating use cases (bug, feature, data_gap, praise) and contrasts with tools like 'ask_pipeworx' for questions.

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

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

Explicitly states when to use: for bugs, features/data_gaps, or praise. Also provides exclusion guidance: 'don't paste the end-user's prompt' and describes feedback format. Mentions rate limits (5 per identifier per day) and that it's free.

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

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

Annotations already set readOnlyHint to true, so the description's behavioral disclosure is supplementary. It adds transparency about scoping (anonymous IP, BYO key hash, or account ID) and the listing behavior when key is omitted, providing useful context beyond annotations.

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

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

Three sentences, each carrying essential information: action, use case, and scoping. No wasted words, front-loaded with purpose, and well-structured.

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

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

Given the tool's simplicity (one optional parameter, read-only), the description covers purpose, usage, behavioral traits, and parameter semantics sufficiently. No output schema exists, but the return behavior (value or list) is implied. Complete for its 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 the schema already documents the key parameter. The description adds that omitting the key lists all values, which is helpful but not extensive. No further parameter details are needed, so baseline score applies.

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

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

Description clearly states the tool retrieves a saved value or lists all keys, with explicit reference to the resource (memories saved via remember) and actions. It distinguishes from sibling tools like remember and forget by naming them, providing high 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?

Description advises when to use the tool: to look up previously stored context without re-deriving it. It mentions pairing with remember/forget, providing clear context for use. However, it does not explicitly state when to avoid using 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?

The description discloses that the tool fans out to multiple sources (SEC EDGAR, GDELT, USPTO) in parallel and returns structured changes with citations. The readOnlyHint annotation is consistent.

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

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

The description is concise with three sentences, front-loaded with a question and examples, and contains 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 adequately explains the return type (structured changes, count, URIs) and covers the tool's complexity (parallel sources, input formats).

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

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

The description adds significant meaning beyond the schema: it explains the 'since' format with examples and a default, clarifies 'value' as ticker or CIK, and states that only company type is supported.

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 as finding recent changes for a company, with example queries. It specifies the verb (find) and resource (company), and distinguishes it from other tools implicitly.

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 with example user queries. It does not mention when not to use or alternatives among siblings, but the guidance is clear and practical.

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?

Annotation readOnlyHint=true already indicates read-only. Description adds no behavioral context like pagination, sorting, or error handling.

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

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

Single sentence, front-loaded, no redundant information. Efficient and to the point.

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?

Missing output schema or description of return format. With two undocumented required parameters, the description is incomplete for an agent to use correctly.

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

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

Schema has three params; only pageSize has a description. Description does not explain id or source, leaving their purpose ambiguous despite being required.

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

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

Description clearly states it lists references cited by one article, specifying verb and resource. It distinguishes from siblings like 'citations' and 'get_article'.

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 when-to-use or alternatives provided. Usage is implied for retrieving references of an article, but no guidance on when to choose this over siblings.

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

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

Annotations declare readOnlyHint=false (write operation). Description adds scoping by identifier, persistence 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?

Three well-structured sentences, front-loaded, every sentence provides unique 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?

Adequately covers key behavioral details (persistence, scoping, pairing) despite no output schema. Missing return value info but acceptable for a simple save tool.

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

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

Schema coverage is 100% with clear descriptions. Description adds examples and context but doesn't significantly enhance meaning beyond schema.

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

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

The description clearly states the tool saves data for later reuse, with specific examples (ticker, address) and distinguishes from siblings recall and forget.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward'. References siblings recall and forget for paired usage, but doesn't specify when not to use.

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

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

Annotations indicate read-only (readOnlyHint: true). Description adds that it returns IDs plus pipeworx:// citation URIs, providing behavioral context beyond annotations. No contradictions.

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

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

Every sentence serves a purpose: primary function, examples, usage guidance, and benefit. Front-loaded with main purpose, 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?

No output schema, but description explains return values (IDs and citation URIs) with examples. Covers usage context and parameter behavior sufficiently, though output structure could be more detailed.

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

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

Schema has 100% description coverage. Description adds examples and usage context for each parameter (e.g., 'For company: ticker, CIK, or name'), significantly enhancing meaning beyond schema.

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

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

The description clearly states the tool looks up canonical identifiers for companies or drugs, specifies ID types (CIK, ticker, RxCUI, LEI), and gives concrete examples. It distinguishes from siblings like entity_profile and compare_entities by focusing on identifier resolution.

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

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

Explicitly advises use 'BEFORE calling other tools that need official identifiers' and notes it replaces 2-3 lookup calls. Provides clear context, though does not explicitly state when not to use.

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

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

Annotations already declare readOnlyHint=true, and the description adds that the tool returns metadata (not full text). The mention of 'lucene-style query' gives useful behavioral context beyond schema. 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?

Single sentence, front-loaded with the key purpose. Every word is informative 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?

The description is adequate but lacks information about return format (e.g., what fields 'metadata' includes) and no output schema is provided. Given the tool's complexity (3 params, pagination), additional detail on results 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% with descriptions for all parameters. The description adds value by explaining the query parameter as 'lucene-style' and providing syntax examples, which aids correct invocation.

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 Europe PMC using a Lucene-style query and returns metadata for matching articles. This distinctly separates it from sibling tools like 'get_article' (single article retrieval) and 'citations'.

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 example query syntax ('CRISPR OR Cas9') implying when to use, but lacks explicit guidance on when not to use or alternatives. It does not direct users to 'get_article' for known IDs or 'citations' for citation data.

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

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

Annotations already declare readOnlyHint=true, which the description is consistent with. It adds significant behavioral context by detailing the return format (verdict types, structured form, citation) and noting that it replaces multiple sequential calls. This is transparent beyond what annotations provide.

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

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

The description is very concise, using only a few sentences to convey purpose, usage, scope, and output. It front-loads the main action and avoids unnecessary details.

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 in detail. It specifies the domain (company-financial claims) and data source (SEC EDGAR + XBRL). Could mention limitations (e.g., only US public companies) or error handling for even higher 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% with a clear description of the 'claim' parameter. The description provides an example claim, which adds marginal value but does not significantly deepen the semantic understanding beyond the schema.

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

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

The description clearly states the tool's purpose: to verify factual claims against authoritative sources. It provides specific verbs (fact-check, validate) and resource (natural-language claim). However, it does not explicitly differentiate from sibling tools that might also handle entity identification or comparisons, which prevents a perfect score.

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 includes usage examples and the general context of when to use (checking truth of a statement). It does not explicitly state when not to use or mention alternatives among sibling tools, such as 'compare_entities' or 'entity_profile', leaving some ambiguity.

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