Statscan

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

With no annotations, the description adequately discloses that Pipeworx picks the right tool, fills arguments, and returns the result, and mentions over 300 sources. However, it does not detail latency, error handling, 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, front-loaded paragraph that efficiently states the purpose, provides usage guidance, and includes examples without any wasted words.

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

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

Given the simple context (one parameter, no output schema), the description is mostly complete: it explains the routing behavior and gives examples. It could optionally note the output format, but it's implied as a natural language answer.

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 sole parameter 'question' is described in the schema with 100% coverage, and the description adds value by explaining it is in natural language and providing illustrative examples.

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 answers natural-language questions by automatically selecting the right data source, and distinguishes it from siblings by noting it routes across many sources, preventing the need to choose a specific Pipeworx tool.

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 (e.g., 'What is X?', 'Look up Y') and implies it's for when you don't want to figure out which tool to call, but does not explicitly list exclusions or alternatives.

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

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

No annotations are provided, so the description carries the full burden. It details the data sources (SEC EDGAR/XBRL for companies, FAERS for drugs) and the specific data fields pulled (revenue, net income, cash, debt; adverse-event counts, FDA approvals, trials). It also mentions returning citation URIs. While it lacks details on side effects, permissions, or rate limits, the information given is substantial and accurate.

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 paragraph that conveys all key information efficiently. It front-loads the core purpose and then adds details on usage, data sources, and output. Every sentence adds value, though 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 absence of an output schema, the description should elaborate on the return value. It only mentions 'returns paired data + pipeworx:// citation URIs', which is vague. The tool's complexity (multiple data sources, comparative output) demands more detail on the output structure (e.g., format, sorting, or how multiple entities are compared) 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?

The input schema has 100% coverage with descriptions for both parameters. The description adds significant value by specifying the format of 'values' (tickers/CIKs for companies, drug names) and giving concrete examples (AAPL, MSFT, ozempic). It also explains how the 'type' parameter maps to different data sources, which is not evident from the schema alone.

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

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

The description clearly states that the tool compares 2–5 companies or drugs side by side. It specifies the verb ('compare'), the resource ('companies or drugs'), and the scope ('2–5'), which is highly specific. It also lists example user queries ('compare X and Y', 'X vs Y', etc.), making the purpose 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?

The description explicitly states when to use the tool: when a user says 'compare X and Y', 'X vs Y', etc., or wants tables/rankings. It also mentions that it replaces 8–15 sequential calls, implying efficiency. However, it does not provide exclusions or alternative tools for single-entity queries, which would push it to a 5.

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

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

No annotations, so description carries burden. Clearly states returns top-N relevant tools with names+descriptions. Behavior is simple and well-described.

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?

Information-dense but not overly long. Every sentence adds value. Could be slightly shorter, but structure is logical.

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 2 params, no output schema, and many siblings, description covers purpose, usage, and return. Could mention if results include IDs or pagination, but sufficient for discovery.

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

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

Schema has 100% coverage with descriptions. Description adds value by clarifying query parameter format with examples and noting limit max.

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 finds tools based on a description of data or task, listing many domains. It distinguishes from sibling tools by positioning itself as a discovery layer.

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 'Call this FIRST when you have many tools available' and describes scenarios (browse, search, look up). Does not explicitly state when not to use, but context makes it clear.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses the returned data types (SEC filings, fundamentals, patents, news, LEI) and the citation format. However, it does not mention potential limitations like pagination, rate limits, or exact number of results, which would enhance transparency.

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

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

The description is three sentences: first sentence states purpose, second gives usage examples and output summary, third provides input guidance. It is front-loaded, concise, and every sentence adds essential information without redundancy.

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

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

Given the tool's complexity (aggregating multiple sources) and no output schema, the description covers the main return types and usage context thoroughly. It mentions citations and input restrictions. Minor omissions include lack of mention of any limits on returned items or performance characteristics, but overall it is sufficiently 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 adds value by reinforcing the type restriction (only 'company'), detailing the value format (ticker or CIK), and explicitly instructing to use resolve_entity for names. This provides practical guidance beyond the schema's field 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 explicitly states it gets everything about a company in one call, with concrete examples like 'tell me about X' and 'research Microsoft'. It distinguishes from sibling tools like resolve_entity by noting that names are not supported. Purpose is clear and specific.

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 (when user asks for a company profile) and when not to use (if only a name is available, use resolve_entity first). This provides clear exclusion and alternative 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?

With no annotations, the description must disclose behavior. It states the deletion action and key requirement but does not mention irreversibility, return value, or error handling (e.g., if key missing). Adequate but could be more 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?

Two concise sentences: first states purpose, second provides usage guidelines. No filler words, every sentence adds value.

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

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

Given the tool's simplicity (1 param, no output schema), description covers purpose, usage timing, and related tools. Lacks details on side effects or error handling, but sufficient for a basic delete operation.

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 parameter description 'Memory key to delete'. Description adds no extra semantic beyond schema, so baseline 3 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 verb 'Delete' and specific resource 'previously stored memory by key'. It distinguishes from siblings like 'remember' and 'recall' by indicating the deletion action.

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 (stale context, task done, clear sensitive data) and mentions related tools 'remember' and 'recall' for pairing, providing clear usage context.

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

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

With no annotations, the description should disclose behavioral traits. It only states the basic operation, omitting details like pagination, order, or limits, providing little beyond the functional purpose.

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 extremely concise with two sentences, front-loading the purpose and a usage hint. Every word 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?

For a simple tool with one optional parameter and no output schema, the description covers the core functionality and provides a practical use case, though it could mention edge cases or the nature of the response.

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 reiterates the default behavior, adding no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states it lists series that changed on a given date, using a specific verb and resource. It provides a use case but does not explicitly differentiate from sibling tools like 'recent_changes'.

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 mentions default behavior and a use case ('useful to detect updated cubes for scheduled refreshes'), but lacks guidance on when not to use the tool or 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 full burden for behavioral disclosure. It clearly states the tool returns a URL without fetching the file, which is transparent. It does not discuss potential rate limits or authentication, but the behavior is simple and adequately described.

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 long, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds value: the first defines what it does, the second clarifies a key behavioral aspect (no file fetching).

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

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

Despite having no output schema, the description fully explains what the tool returns (a direct URL) and its purpose (for full cube CSV download). It is complete for a simple URL-returning tool and leaves no ambiguity about its function or return value.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters like product_id and language. It does not mention the language parameter or provide additional context, so it meets the minimum but does not exceed.

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 StatCan-hosted URL for downloading a full cube as CSV. It specifies the verb 'Return', the resource 'URL for cube CSV download', and distinguishes itself from fetching behavior. This is distinct from siblings like get_latest_data which fetch actual 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?

The description explicitly notes that the tool does not fetch the file but provides a URL for download, guiding agents to use this tool for obtaining download links rather than data. While it does not list alternatives, the context of siblings implies when to use this versus data-fetching 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?

No annotations provided. Description uses 'Fetch' implying read-only, but doesn't explicitly state safety, authentication needs, or rate limits. Adequate for a simple fetch operation.

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

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

Two sentences: first details what is fetched, second states purpose. No unnecessary words, perfectly front-loaded.

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

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

Given no output schema, description gives good sense of return content (dimensions, member trees, etc.). Lacks details on format or structure, but sufficient for a metadata-lookup tool with single parameter.

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?

Only parameter product_id is fully described in schema (100% coverage). Description adds no additional parameter information beyond what schema 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?

Description clearly states it fetches full metadata for a cube, listing specific content (dimensions, member trees, frequency, geography, last release) and connects to sibling get_latest_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 tells when to use: 'Use to figure out a coordinate string for get_latest_data.' Provides clear context for usage but doesn't mention when not to use or alternatives among 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?

Lacking annotations, the description only reveals the coordinate format (10-position, dot-separated, trailing zeros) but does not disclose behavioral traits such as read-only safety, error handling, rate limits, or what happens with invalid input. The tool's side effects and restrictions are not addressed.

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 3 sentences, each serving a purpose: stating the action, explaining the coordinate format, and noting trailing zeros. It is front-loaded and free of redundancy, though the coordinate explanation could be more 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?

For a tool with no output schema, the description partially compensates by detailing the coordinate parameter but lacks return value information, behavioral traits, and usage context. It adequately covers parameter semantics but leaves gaps in overall 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?

The input schema already provides descriptions for all 3 parameters (100% coverage). The description adds significant value by detailing the coordinate format (10-position, dot-separated, trailing zeros) and referencing get_cube_metadata for mapping, which goes 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 states the tool retrieves the latest N observations for a series within a cube, with a specific verb and resource. It explains the unique coordinate format, but does not explicitly differentiate from sibling tools like get_changed_series or get_cube_metadata, though the context implies its specialized use.

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 advises using get_cube_metadata to map members to positions, which provides indirect usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_changed_series) or when not to use it, leaving room for 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?

Discloses large response size (~3,000 cubes) and recommends caching/filtering, which is crucial behavioral info. No annotations exist, so description carries full burden; it covers the main trait but omits read-only status.

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 concise sentences, front-loaded with purpose and key actions. 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 purpose, output fields, and usage guidance. Lacks details on ordering, errors, or auth, but is sufficient for a simple list 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?

No parameters exist, so baseline is 4 per guidelines. Description adds value by explaining output fields, which is relevant for parameter-less tool.

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 all cubes with specific fields (productId, title, etc.) and directs to use productId with other tools, distinguishing it from siblings like get_cube_metadata.

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 using productId with other tools and warns about large response, suggesting client-side filtering/caching. Lacks explicit alternatives or when-not-to-use, but the size warning is 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?

With no annotations provided, the description carries full burden. It discloses rate limits (5 per identifier per day), that it is free and doesn't count against quota, and that feedback affects roadmap. This fully informs the agent of behavioral constraints.

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 tool's purpose, then guidelines, then constraints. Every sentence earns its place without redundancy. It is concise yet comprehensive.

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?

There is no output schema, but that is acceptable for a feedback tool (expected response is confirmation). The description covers all needed context: purpose, when to use, parameter guidance, behavior, and limitations. It is complete for an AI agent to invoke correctly.

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

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

Input schema has 100% coverage with descriptions for all parameters. The description adds value by echoing enum meanings and emphasizing that context is optional. While schema is sufficient, the description reinforces usage without adding new semantics 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 is for sending feedback to the Pipeworx team about bugs, features, data gaps, or praise. It specifies distinct use cases and differentiates itself from sibling data retrieval 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 explicitly defines when to use the tool for each feedback type (bug, feature, data_gap, praise) and provides instructions on what to include (e.g., reference tools/packs, avoid pasting user prompts). It also mentions that the team reads digests daily.

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 scoping to identifier and pairing with siblings; no annotations exist, so description carries full burden. Missing details on return format or error handling but sufficient for a simple read operation.

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

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

Three sentences, front-loaded with core functionality, no wasted words.

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

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

Given no output schema and optional single parameter, description covers retrieval, listing, and scope adequately, though return value format could be hinted.

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?

Describes the key parameter's meaning and explicitly notes omitting it lists all keys, adding value beyond the schema's 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 retrieves a saved value by key or lists all keys when omitted, distinguishing it from siblings like remember and forget by specifying opposite actions.

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 context for when to use (look up stored context) and pairs with remember/forget, but does not explicitly state when not to use or name alternatives.

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

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

With no annotations, the description carries the full burden. It discloses the parallel fan-out to three sources, the return structure (structured changes, total_changes count, citation URIs), and details the 'since' parameter format. It does not mention rate limits or latency, but the read-only nature and key behavioral traits are well explained.

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, using only a few sentences. It is front-loaded with the core purpose, then provides example queries, explains the data sources, and clarifies the output. Every sentence adds value, and there is 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 explains the return format and the data sources. It covers all necessary aspects: what the tool does, when to use it, how to parameterize it, and what to expect in the response. For a tool with three parameters and no output schema, this is exceptionally 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 adds practical examples and guidance, such as using '30d' for typical monitoring and explaining that 'value' can be a ticker or CIK. This extra context helps an agent use the parameters correctly, making it a 4.

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

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

The description explicitly states the tool's purpose: retrieving recent changes for a company over a specified time window. It gives example queries like 'what's happening with X?' and 'any updates on Y?', and specifies the three data sources (SEC EDGAR, GDELT, USPTO) that are fanned out. This clearly distinguishes it from sibling tools such as entity_profile or compare_entities.

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

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

The description provides clear usage guidance by listing example user intents that trigger this tool (e.g., 'brief me on what happened with Microsoft this quarter'). It also notes that it is for monitoring changes. However, it does not explicitly state when not to use it or point to alternatives, leaving room for ambiguity in some scenarios.

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

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

No annotations exist, so description carries full burden. It discloses scoping by identifier, persistence differences (authenticated vs anonymous), and that data is key-value. However, it does not mention overwriting behavior or conflict resolution.

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, each earning its place: main action, when to use, storage details, and sibling references. Front-loaded with the core purpose.

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

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

Given no output schema and no annotations, the description covers all essential aspects: purpose, usage, parameters, storage behavior, durability, and relationship to siblings. Nothing critical is missing.

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

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

Schema already provides descriptions for both parameters (key and value). The description adds value by giving examples of key patterns and clarifying that value can be any text, enhancing 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 verb ('Save') and resource ('data'), and provides examples of what to store. It distinguishes from sibling tools 'recall' and 'forget' by positioning itself as the storage action.

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 'Use when you discover something worth carrying forward' and lists concrete scenarios (ticker, address, preference). It also mentions pairing with recall and forget for retrieval and deletion.

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 return value includes pipeworx:// citation URIs, but with no annotations, more behavioral details (rate limits, failure modes, permissions) are absent. Examples partially compensate, but transparency is moderate.

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 purpose, then examples, then usage guidance. Every sentence adds value; no redundancy.

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

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

Given no output schema, description covers purpose, inputs, examples, and return URIs. Lacks error handling or missing entity scenarios, but sufficient for typical use.

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

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

Schema covers 100% of parameters with descriptions. Description adds value with concrete examples showing input/output mappings and clarifies acceptable input formats 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?

Description clearly states the verb 'look up' and the resource 'canonical/official identifier', with specific ID systems (CIK, ticker, RxCUI, LEI). Examples distinguish from sibling tools by emphasizing it replaces multiple lookup calls and must be used before other 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?

Explicitly states when to use (when you need official identifiers for SEC, stock data, FDA) and provides sequencing guidance ('Use this BEFORE calling other tools'). Lacks explicit when-not or direct sibling comparison, but context is strong.

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 adequately discloses behavior: it returns a verdict with five types, extracted form, actual value with citation, and percent delta. It also mentions efficiency gains (replaces 4-6 sequential calls). No destructive actions or authentication details are needed for this read-only validation 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?

The description is concise: two sentences plus a list of verdict types. It is front-loaded with the core purpose, then expands on specifics. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (1 parameter, no output schema), the description covers the output format, domain restriction, and example usage. It does not mention potential errors or prerequisites, but the level of detail is sufficient for an agent to correctly invoke the 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?

The single 'claim' parameter is fully described with schema coverage 100%. The description adds contextual examples (e.g., 'Apple's FY2024 revenue…') and clarifies that the claim must be a natural-language factual statement, which goes beyond the schema's basic 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 specifies the exact verb (fact-check, verify, validate) and resource (natural-language factual claim against authoritative sources). It also highlights the specific domain (company-financial claims via SEC EDGAR), making it easy to distinguish from sibling tools like ask_pipeworx 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 clearly states when to use the tool with explicit examples ('When an agent needs to check whether something a user said is true…'). It implies limitations by mentioning 'v1 supports company-financial claims', but does not explicitly state when not to use or suggest alternatives.

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