patents

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key traits: it uses Pipeworx to pick tools and fill arguments, and returns results. However, it lacks details on limitations (e.g., rate limits, data source availability, error handling) or performance aspects. The description doesn't contradict annotations, but for a tool with no annotations, it provides only moderate behavioral insight.

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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by explanatory details and examples. Every sentence earns its place by clarifying functionality or providing concrete use cases, with no redundant or vague language. It efficiently conveys the tool's value in a compact format.

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 (natural language querying with backend tool selection) and no output schema, the description is mostly complete. It explains the process and gives examples, but lacks details on output format, error responses, or constraints like query length. With no annotations, it could benefit from more behavioral context, but it adequately covers the core functionality for an agent to use it correctly.

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

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

The input schema has 100% description coverage, with the 'question' parameter well-documented as 'Your question or request in natural language.' The description adds value by emphasizing 'plain English' and providing examples (e.g., 'Look up adverse events for ozempic'), which clarifies the expected format and scope beyond the schema's basic definition. With only one parameter, this extra context is sufficient for a high score.

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: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool'), distinguishing it from sibling tools like search_patents or get_patent that require specific parameters. The examples further clarify its broad, natural-language query capability.

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 context on when to use this tool: for natural language questions where you don't need to browse tools or learn schemas. It implies usage by stating 'No need to browse tools or learn schemas' and gives examples like 'What is the US trade deficit with China?' However, it doesn't explicitly state when not to use it or name alternatives among siblings, such as using search_patents for structured patent queries.

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

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

No annotations are provided, so the description carries full responsibility. It mentions return type (paired data + URIs) but does not disclose whether the tool is read-only or if there are side effects. The description implies a safe query operation, but explicit safety traits are missing.

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 with no fluff. The first sentence states the core function, and the second adds details on types and output. 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?

For a tool with 2 parameters and no output schema, the description covers the purpose, input constraints, and output format. It also mentions the efficiency gain. No gaps are apparent.

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

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

Schema coverage is 100% with descriptive parameter entries. The description adds value by explaining what each type returns (e.g., revenue for company, trials for drug), which goes beyond the schema's simple enum. This helps the agent understand the purpose of each parameter.

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

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

The description clearly states it compares 2-5 entities side by side, specifies two types (company and drug) with distinct data fields, and highlights efficiency gains. This is specific and distinct from sibling tools like search_patents or resolve_entity.

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

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

The description explains what the tool does and when to use it (comparing entities). It does not explicitly state when not to use it, but the context and sibling tools make alternatives clear. A slight improvement would be to mention that it is not suitable for single-entity queries.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it performs a search based on natural language queries, returns relevant tools with metadata, and has a specific use case (large catalogs). However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving some behavioral aspects unspecified.

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 perfectly concise and front-loaded. The first sentence states the core functionality, the second explains the return value, and the third provides crucial usage guidance. Every sentence earns its place with no wasted words, making it highly efficient 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 moderate complexity (search functionality with 2 parameters) and the absence of both annotations and output schema, the description does a good job of explaining what the tool does and when to use it. However, it doesn't describe the return format (beyond 'names and descriptions') or potential search limitations, leaving some contextual gaps that could be important for an agent.

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

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

The input schema has 100% description coverage, providing full documentation for both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain query formatting nuances or limit implications). This meets the baseline of 3 since the schema already does the heavy lifting, but no extra value is added.

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 with specific verbs ('search', 'returns') and resources ('Pipeworx tool catalog', 'most relevant tools with names and descriptions'). It distinguishes from siblings by focusing on tool discovery rather than patent/inventor searches, making the purpose unambiguous and well-defined.

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

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

The description provides explicit guidance on when to use this tool: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This gives clear context about usage scenarios (large tool catalogs) and positioning (first step in tool selection), with no misleading or missing 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?

Without annotations, the description carries the full burden. It discloses that the tool aggregates data from multiple sources, returns pipeworx:// citation URIs, and is read-only in nature. However, it omits details about response structure, rate limits, or error handling, which slightly reduces completeness.

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 four sentences, each providing critical information without redundancy. It front-loads the purpose, lists key outputs, mentions output format, and gives an alternative—all in a compact form.

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

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

Given the absence of an output schema, the description should explain return values more thoroughly. While it mentions pipeworx:// URIs, it lacks details on the structure or potential variations. However, the tool is simple (2 params) and the guidance is clear, so completeness is good but not perfect.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context: type is limited to 'company', value can be a ticker or CIK, and names are not supported (recommending resolve_entity). This enhances understanding 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?

The description clearly states the tool returns a 'Full profile of an entity across every relevant Pipeworx pack in one call,' listing specific data types (SEC filings, XBRL data, patents, news, LEI) and explicitly distinguishes from the alternative usa_recipient_profile for federal contracts. This makes the purpose unambiguous and differentiates it from sibling tools.

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

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

The description provides explicit guidance: it replaces 10-15 sequential calls, advises against use for federal contracts (pointing to usa_recipient_profile), and notes that names are unsupported, recommending resolve_entity as a prerequisite. This covers when and when not to use the 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?

No annotations are provided, so the description carries full burden. While 'Delete' implies a destructive mutation, the description doesn't disclose whether deletion is permanent, reversible, requires specific permissions, or has side effects. It mentions the target ('stored memory') but lacks behavioral details like confirmation prompts or error conditions.

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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place in conveying the essential function.

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 destructive tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'delete' entails (e.g., permanent removal, soft delete), what happens on success/failure, or how this interacts with sibling tools. Given the mutation nature and lack of structured data, more behavioral context is needed.

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

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

Schema description coverage is 100% for the single parameter 'key', which is documented as 'Memory key to delete'. The description adds minimal value beyond this, only implying the parameter's purpose without additional context like key format or examples. With high schema coverage, the 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 ('Delete') and the resource ('a stored memory by key'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'recall' or 'remember', which likely interact with the same memory system.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when deletion is appropriate, or what happens to deleted memories. With siblings like 'recall' and 'remember', there's no indication of when deletion should be chosen over retrieval or storage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('Get') and specifies the scope ('US patent'), but doesn't mention potential limitations like rate limits, authentication requirements, error conditions, or whether the data is real-time. The description adds basic context but lacks comprehensive behavioral traits.

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 efficiently structured in two sentences: the first states the purpose and parameter, the second lists the returned fields. Every element serves a purpose with zero wasted words, making it appropriately sized and front-loaded with the core functionality.

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 low complexity (single parameter, no output schema, no annotations), the description provides adequate context for basic usage. It covers what the tool does, what parameter it needs, and what data it returns. However, without an output schema, it could benefit from more detail about the return structure beyond the field names listed.

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

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

Schema description coverage is 100% with the single parameter 'number' well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'patent number' and providing an example format in parentheses, but doesn't significantly enhance parameter understanding beyond what the structured schema already provides.

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

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

The description clearly states the verb ('Get full details') and resource ('specific US patent'), specifying it's for a single patent identified by number. It distinguishes from sibling tools search_inventors and search_patents by focusing on retrieval of complete information for a specific patent rather than searching across multiple patents or inventors.

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 context by specifying 'by patent number' and listing the returned fields, suggesting this tool should be used when you have a specific patent number and need comprehensive details. However, it doesn't explicitly state when NOT to use it or name alternatives like the sibling search tools, missing full explicit 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?

Discloses rate limiting (5 per day) and privacy guideline (no verbatim prompts). No annotations provided, so description carries behavioral disclosure burden. Could mention if feedback is stored or anonymous, but sufficient for a feedback tool.

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

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

Three sentences: purpose, usage guidance, and constraints. No wasted words, front-loaded with key information.

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

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

No output schema needed (fire-and-forget feedback). Schema fully documents parameters. Description covers all necessary usage context. Complete for a simple feedback 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 description coverage is 100% with detailed descriptions for type (enum), context (optional object), and message (max 2000 chars). Description adds no significant meaning beyond schema, but baseline is 3 due to high 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?

Description clearly states 'Send feedback to the Pipeworx team' and enumerates use cases: bug reports, feature requests, missing data, or praise. This distinguishes it from sibling tools which are data retrieval or interaction tools.

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

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

Provides explicit guidance on when to use (for feedback), what to avoid (do not include user prompt verbatim), and rate limits (5 per day per identifier). Alternatives are clear from sibling tool names.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the dual functionality (retrieve by key or list all) and mentions persistence across sessions, which is valuable context. However, it doesn't address potential limitations like memory size constraints, retrieval failures, or authentication requirements.

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

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

The description is efficiently structured in two sentences: the first explains the core functionality, and the second provides usage context. Every word earns its place with no redundancy or unnecessary elaboration.

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

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

For a tool with one optional parameter, 100% schema coverage, and no output schema, the description provides adequate context about what the tool does and when to use it. It could be more complete by hinting at the return format (e.g., structured data vs. raw text) or error conditions, but it covers the essentials well.

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

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

Schema description coverage is 100%, so the schema already documents the optional 'key' parameter. The description adds meaningful context by explaining the semantic effect of omitting the key ('list all stored memories') and relating it to retrieving saved context, which goes beyond the schema's technical specification.

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 with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes this from sibling tools like 'remember' (store) and 'forget' (delete) by focusing on retrieval operations.

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

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

The description provides explicit guidance on when to use this tool: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter to list all memories, offering clear operational context without needing to reference alternatives 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?

No annotations were provided, so the description carries the full burden. It details that the tool fans out to multiple sources in parallel, accepts both ISO dates and relative time strings, and returns structured changes with counts and URIs. This is transparent, but could mention potential latency 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?

The description is concise at 4 sentences, with the core purpose front-loaded. Every sentence adds value: sources, date formats, return structure, and use cases. No redundant or wasted wording.

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 (multi-source fan-out) and lack of output schema or annotations, the description covers key aspects: sources, date formats, response components, and use cases. It does not mention edge cases like no results or error handling, but overall is reasonably 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?

Input schema covers all 3 parameters (100% coverage). The description adds meaning beyond the schema by explaining the accepted formats for 'since' (relative like '7d'), that 'type' is currently limited to 'company', and that 'value' can be a ticker or CIK. This extra context is valuable.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time.' It specifies the entity type (company) and the sources it fans out to (SEC EDGAR, GDELT, USPTO), effectively distinguishing it from sibling tools like entity_profile or compare_entities.

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

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

Explicit usage guidance: 'Use for "brief me on what happened with X" or change-monitoring workflows.' This provides clear context for when to use the tool, though it does not explicitly mention when not to use it or list alternatives.

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

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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses persistence differences (authenticated users get persistent memory, anonymous sessions last 24 hours) and the tool's role in session management. It doesn't cover rate limits or error handling, but provides key operational details beyond basic functionality.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage context and behavioral details. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick comprehension.

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

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

Given the tool's moderate complexity (storage with session-based persistence), no annotations, and no output schema, the description is mostly complete: it covers purpose, usage, and key behavioral traits. However, it lacks details on return values or error cases, which would be helpful for full 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description does not add meaning beyond what the schema provides (e.g., no additional syntax or format details). Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Store a key-value pair') and resource ('in your session memory'), distinguishing it from sibling tools like 'forget' (remove) and 'recall' (retrieve). It explicitly mentions what can be stored ('intermediate findings, user preferences, or context across tool calls'), making the purpose 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 provides clear context on when to use this tool ('to save intermediate findings, user preferences, or context across tool calls'), but does not explicitly mention when not to use it or name alternatives (e.g., 'recall' for retrieval). It implies usage for persistence across sessions but lacks explicit 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?

No annotations are provided, so the description should fully disclose behavior. It describes the read operation (resolve, return IDs) and output details, but lacks explicit statements about safety (e.g., no mutation, idempotency) or error conditions.

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

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

Three sentences, front-loaded with purpose, then details, then benefit. Every sentence earns its place 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?

The tool has no output schema, but the description compensates by enumerating returned fields (ticker, CIK, name, URIs) and noting efficiency gains. It could mention failure modes or case sensitivity, but is largely complete for a simple lookup.

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 providing concrete examples ('AAPL', '0000320193', 'Apple') and clarifying the value parameter's accepted formats beyond the schema's generic description.

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

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

The description clearly states the tool resolves an entity to canonical IDs, specifying the supported type (company) and acceptable inputs (ticker, CIK, name). It distinguishes from sibling tools like search_patents by focusing on entity 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?

The description indicates it replaces 2–3 lookup calls, providing strong usage context. It could be more explicit about when not to use it, but the version note (v1: type=company) and examples guide appropriate 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?

No annotations are provided, so the description carries the full burden. It mentions the return data (inventor name, location, patent numbers) but does not disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, error handling, or pagination details beyond the 'per_page' parameter in the schema.

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

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

The description is two sentences with zero waste: the first sentence states the purpose and scope, and the second specifies the return values. It is appropriately sized, front-loaded with key information, and efficiently 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 no annotations and no output schema, the description provides basic purpose and return data, but lacks details on behavioral aspects like safety, performance, or error handling. For a search tool with two parameters and 100% schema coverage, it is adequate but has clear gaps in transparency.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'per_page') with their types and descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for 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 the specific action ('Search'), resource ('US patent inventors'), and filtering criterion ('by last name'), distinguishing it from sibling tools like 'get_patent' (likely retrieves a single patent) and 'search_patents' (searches patents rather than inventors). It provides a complete picture of what the tool 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?

The description implies usage for searching inventors by last name, but does not explicitly state when to use this tool versus alternatives like 'search_patents' or provide any exclusions or prerequisites. The context is clear but lacks explicit guidance on tool selection.

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

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

No annotations are provided, so the description carries the full burden. It mentions the search scope (US patents, abstracts) and return fields, but lacks behavioral details such as pagination behavior (implied by 'per_page' parameter), rate limits, authentication needs, or error handling. The description adds some context but is insufficient for a mutation-free tool with no annotation coverage.

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

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

The description is two concise sentences with zero waste: the first states the action and scope, the second lists return fields. It is front-loaded and appropriately sized for a simple search tool, with every sentence earning 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 low complexity (search with 2 parameters), 100% schema coverage, and no output schema, the description is minimally adequate. It covers purpose and return fields but lacks behavioral context (e.g., pagination, limits) and explicit usage guidelines. Without annotations, it should do more to compensate, but it meets the baseline for a simple 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 description coverage is 100%, so the schema already documents both parameters ('query' and 'per_page') with descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as search syntax or result ordering. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool searches US patents by keyword, matching against abstracts, and returns specific fields (patent number, title, date, inventors, assignee). It distinguishes from 'get_patent' (likely a detail lookup) and 'search_inventors' (inventor-focused search), though not explicitly. The purpose is specific but lacks explicit sibling differentiation.

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 keyword-based patent searches against abstracts, but does not explicitly state when to use this tool versus alternatives like 'search_inventors' or 'get_patent'. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name and description.

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

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

With no annotations, the description discloses key traits: v1 support, specific data source, returned verdict and details, and efficiency gain (replaces 4-6 agent calls). Missing minor details like rate limits or error behavior, but overall transparent.

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

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

Three sentences, front-loaded with purpose, each sentence adds unique value. No redundancy or filler.

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

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

For a single-parameter tool without output schema, the description covers purpose, supported claims, return values, and efficiency. Does not mention error conditions or output structure details, but these are partially implied by the listed return fields.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds example values for the claim parameter but does not significantly enrich 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?

Clearly states the tool's function: fact-check natural-language claims against authoritative sources, specifically company-financial claims via SEC EDGAR + XBRL. Also distinguishes from sibling tools, none of which handle claim validation.

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 supported claim types (company-financial) and data source, giving clear context for when to use. However, it lacks explicit 'when not to use' or alternative tool suggestions, though no sibling alternatives exist.

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