Entreprises Fr

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

No annotations provided, so description carries full burden. It discloses routing across many sources, picking the right tool, and returning results. However, it doesn't disclose limitations, authentication needs, or behavior when no source matches, which is a gap.

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 about 100 words, front-loaded with purpose, then usage, then sources, then examples. Every sentence adds value with no fluff.

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

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

Given one parameter, no output schema, and no annotations, the description is mostly complete: purpose, usage, how it works, examples. It lacks mention of return format or error handling, but these are minor given the tool's simplicity.

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

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

Schema coverage is 100% with one required parameter 'question' described as 'Your question or request in natural language'. The description adds rich meaning by giving examples of questions and explaining the routing behavior, exceeding schema documentation.

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

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

The description clearly states the tool answers natural-language questions by routing to the right data source, with specific verb ('answer') and resource ('natural-language question'). It distinguishes from siblings by explaining it's a meta-tool that picks the right tool, unlike specific siblings like compare_entities or search.

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

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

The description explicitly states when to use (when user asks 'What is X?', etc., and you don't want to figure out which tool to call). It implies when not to use (when you already know the specific tool) but does not explicitly state alternatives 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 already declare readOnlyHint=true and openWorldHint=true. Description adds specifics: resolves market, classifies bet type, fans out to relevant data packs, returns evidence packet and comparison. No contradiction.

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

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

Description is detailed but not verbose. Each sentence adds value, starting with purpose, then process, then use cases. Slightly long but efficient. Could be tightened without losing clarity.

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 adequately explains return (evidence packet + comparison). Covers inputs, internal logic (resolving, classifying, fanning out), and output format. Differentiated from siblings effectively.

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

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

Schema coverage is 100%, so baseline is 3. Description adds meaning: market parameter accepts slug, URL, or question text; depth parameter explains 'quick' vs 'thorough' (default thorough). These details aid correct usage.

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 it researches a Polymarket bet by pulling relevant Pipeworx data. Specifies inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). Distinguishes from siblings as the core demo product that converts better.

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 use cases ('should I bet on X?', 'what does the data say?', 'is there edge?'). Implicitly tells when to use (any Polymarket bet research). No explicit when-not or alternatives, but the context is clear and it differentiates from sibling tools.

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

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

With no annotations provided, the description carries the full burden. It discloses data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), output format (paired data + pipeworx:// URIs), and behavior (replaces multiple calls). 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?

The description is concise and front-loaded with the core function. It efficiently uses three sentences plus bullet-style clarifications. Every sentence adds 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 (two entity types, multiple data sources) and lack of output schema, the description adequately covers inputs, outputs, and sources. It could mention pagination or result size limits, but overall it is sufficient for an agent to understand and 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining what each type ('company' or 'drug') retrieves and providing example values for the 'values' parameter. This goes beyond the schema's minimal 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 compares 2–5 companies or drugs, enumerates specific use cases (e.g., 'compare X and Y', 'X vs Y'), and distinguishes what data is pulled for each type. This is specific and resource-oriented, setting it apart from siblings like entity_profile or search.

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

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

The description explicitly lists when to use the tool (user phrases like 'compare X and Y', 'how do X, Y, Z stack up') and mentions efficiency (replaces 8–15 sequential calls). It lacks explicit when-not-to-use instructions, but the guidance is clear and actionable.

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

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

No annotations provided, so description carries full burden. It states the tool searches by query, returns top-N tools with names and descriptions, and lists many domains. It does not mention side effects, but it is a read-only discovery tool. The description adds context beyond 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 a single paragraph that efficiently conveys purpose, usage, and scope. While slightly verbose with the domain list, it is well-structured and each part 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?

With no output schema, the description explains that it returns 'top-N most relevant tools with names + descriptions.' It covers enough context for an agent to understand what the tool does and when to use it, though the exact output format could be more explicit.

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 parameter descriptions in the schema are already clear (query is natural language, limit is max number). The description does not add new parameter details, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists specific domains (SEC filings, financials, etc.) and explicitly says it returns top-N most relevant tools, distinguishing it from sibling tools like search or entity_profile.

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 instructs: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use and implies when not to use (when a specific tool is already known).

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

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

No annotations provided, so description carries full burden. It details return data (SEC filings, financials, patents, news, LEI) and notes only 'company' type supported. Lacks mention of rate limits or authentication, but sufficiently 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?

Single sentence with front-loaded purpose, no wasted words. Every sentence provides useful 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, but description explains return data. Parameter descriptions are clear and complete. Includes aggregation context and citation URIs. Sufficient for 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 coverage 100%, baseline 3. Description adds value by explaining parameter meaning: type is only 'company', value is ticker or CIK with examples, and explicitly states names are not 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?

Description clearly states 'Get everything about a company in one call' with specific verb and resource. It lists use cases and distinguishes from siblings by emphasizing aggregation from multiple sources.

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

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

Explicitly states when to use (e.g., 'tell me about X' queries) and provides constraints (names not supported, use resolve_entity first). Clear guidance on 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 provided, so description carries full burden. It states the delete action but does not mention error handling (e.g., missing key) or irreversibility. Still, the behavior is straightforward and the description is clear enough.

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, front-loads the action and context. No unnecessary words, efficient and clear.

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

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

Given a single required parameter, no output schema, and a simple operation, the description fully covers the needed information. Sibling context further aids understanding.

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 description 'Memory key to delete'. The tool's description adds no extra meaning beyond the schema, so 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?

Description clearly states verb 'delete' and resource 'memory by key'. It distinguishes from sibling tools 'remember' and 'recall' by implication of being the delete 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?

Explicitly specifies when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also pairs with 'remember' and 'recall', providing 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 carries full burden for behavioral disclosure. It states only the action ('Fetch'), but does not mention idempotency, side effects, authentication needs, rate limits, or any constraints. While fetch is inherently read-only, the description does not explicitly confirm this or address potential errors.

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

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

The description is a single, front-loaded sentence that immediately states the verb and resource. It is concise with no extraneous words. Every word contributes to understanding the tool's 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 has only one required parameter, no nested objects, and no output schema, the description minimally covers functionality. It explains what is fetched (legal unit and establishments) and the input format. However, it does not describe the return structure or any caveats, which would be helpful but not critical for a simple fetch.

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% (siren described as '9-digit SIREN identifier'). The description repeats this as 'by SIREN (9 digits)', adding no new meaning beyond the schema. Baseline score applies because schema already covers parameter semantics.

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 fetches a single legal unit with all its establishments using a SIREN identifier. It specifies the verb 'Fetch', the resource 'legal unit with all its establishments', and the exact input format 'SIREN (9 digits)'. This distinguishes it from sibling tools like compare_entities or entity_profile.

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 does not mention scenarios where other tools would be more appropriate, nor does it list prerequisites or context. Only 'by SIREN (9 digits)' hints at the input requirement, but no usage direction is given.

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

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

No annotations are present, so description carries full burden. It does not disclose pagination behavior, default radius, coordinate system details, or any side effects beyond listing. Minimal 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?

Two sentences with no waste. Very concise, but could include more context without becoming verbose. However, it is not over-verbose.

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 6 parameters and no output schema, the description is too brief. It doesn't mention pagination, radius limits, or filtering by APE code, which are essential for correct usage.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds no additional meaning beyond the schema, thus baseline score 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 clearly states it lists establishments near a geo coordinate, providing a specific verb and resource. It distinguishes from siblings like 'search' by focusing on geographic radius, though it could be more precise about coordinate 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?

Provides a use case 'all businesses near ...' but no explicit when-to-use or when-not-to-use compared to other tools. No exclusions or alternatives mentioned.

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, but the description fully compensates by disclosing rate limits (5 per identifier per day), that it's free and doesn't count against quota, and that the team reads digests daily affecting roadmap.

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 and well-structured; every sentence adds value. Front-loaded with purpose, followed by usage guidance and behavioral details. No unnecessary words.

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

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

No output schema, but description explains outcome (team reads, roadmap impact). Covers input guidance well. Could mention expected response or confirmation, but sufficient for a 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 coverage is 100%, so the schema already documents parameters. The description adds context for the 'type' enum values and advises describing issues in terms of Pipeworx tools/packs, providing slight extra value.

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: telling the Pipeworx team about bugs, missing features, or praise. It distinguishes itself from sibling tools by being a feedback mechanism, not a data retrieval or action 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?

Explicitly states when to use: for bugs, feature requests, data gaps, or praise. Also tells what not to do: 'don't paste the end-user's prompt.' Provides clear context for each feedback type.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds value by explaining the algorithm (walking child markets, sorting, reporting violations) and the return structure. No contradictions with annotations.

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

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

The description is well-structured and informative, covering the logic, example, and return format. It is slightly verbose but every sentence contributes to understanding. Could be trimmed slightly, but overall efficient.

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, the description fully explains its purpose, operation, and output. The input schema is simple, annotations provide safety context, and the description covers the return format even without an output schema.

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 new meaning beyond the schema for the single parameter; it repeats the same information (slug or URL).

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: finding arbitrage opportunities by checking monotonicity violations in Polymarket events. It uses a specific verb ('Find arbitrage opportunities') and resource, and explains the logic, distinguishing it from sibling tools like polymarket_edges.

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 when to use the tool: when an event has multiple 'by [date]' or 'by [threshold]' markets. It provides a clear condition and reasoning. While it does not explicitly list alternatives, the context is sufficient for 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?

Annotations indicate read-only and open-world behavior. The description adds detailed context: it uses external data sources (FRED, coinpaprika), fetches price history once per asset, groups by asset, and ranks by edge magnitude. It also notes it's V1 covering crypto-price bets, providing transparency on 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 informative but slightly verbose. It covers purpose, method, and use case in two sentences, but the first sentence is dense. Still, it's well-structured and 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?

For a discovery tool with three parameters and no output schema, the description is quite complete: it explains the algorithm, data sources, output structure (ranked edges with suggested direction), and the intended question it answers. Minor gaps like error handling or performance notes, but sufficient 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?

All three parameters have descriptions in the schema, achieving 100% coverage. The description does not add significant extra meaning beyond the schema, so 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 clearly states the tool's purpose: scanning high-volume Polymarket markets to find where Pipeworx data disagrees with market prices, using a specific model (lognormal from FRED + coinpaprika) and returning ranked edges. It distinguishes itself by focusing on opportunity discovery without manual browsing.

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 targets the 'what should I bet on today' use case, explaining when to use the tool. However, it does not mention when not to use it or provide direct comparisons with sibling tools like polymarket_arbitrage or bet_research.

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

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

No annotations provided, so the description carries the full burden. It discloses the read-only nature (retrieve/list), scoping to anonymous IP, BYO key hash, or account ID, and pairing with other tools. Does not cover rate limits or error cases, but is strong.

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 of three sentences, each serving a distinct purpose: core function, usage context, and tool relationships. 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?

For a simple tool with one parameter and no output schema, the description is complete. It explains the two modes of operation (retrieve/list), scoping, and pairing with sibling tools. No gaps for agent decision-making.

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 one optional parameter 'key' with 100% schema description coverage. The description adds value by explaining that omitting the key lists all saved keys and provides context on the purpose of the key, beyond the schema's brief 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 value saved via 'remember' or lists all keys if the key argument is omitted. It distinguishes from siblings by explicitly naming 'remember' and 'forget' as paired 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 when-to-use guidance: 'look up context the agent stored earlier' and contrasts with alternatives by pairing with 'remember' and 'forget'. It also notes scoping to user identifier.

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 reveals key behaviors: parallel fan-out to three sources, accepted date formats (ISO and relative), and return structure (structured changes + count + URIs). This adds significant value beyond the input schema, though it omits potential rate limits 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 concise, front-loaded with the core purpose, and uses example queries to illustrate use. Every sentence adds value—no fluff or repetition. It is well-structured and quickly scannable.

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

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

Despite lacking an output schema, the description states the return format (structured changes, count, URIs). It covers the 3 parameters well and explains the parallel fan-out. It could mention limitations (e.g., maximum date range) but overall is complete for typical agent invocation.

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 enriches parameters: 'type' is clarified as currently supporting only 'company'; 'since' gets explicit examples of ISO and relative formats; 'value' explains ticker or CIK. This goes beyond the schema and helps the agent select correct values.

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: retrieving recent changes for a company over a specified period. It includes example user queries that strongly hint at its usage, and the name 'recent_changes' is self-explanatory. While it does not explicitly distinguish from siblings, the unique focus on recent changes across multiple data sources makes it distinct.

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 is provided through example queries like 'what's happening with X?' and 'brief me on what happened with Microsoft this quarter'. The description also explains the parallel fan-out to SEC EDGAR, GDELT, and USPTO. However, it does not mention when not to use this tool or suggest alternatives, which would have made it 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 provided, so description carries full burden. Discloses scoping by identifier, persistence differences for authenticated vs anonymous sessions, and 24-hour retention. Adds meaningful behavioral context.

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

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

Four sentences, front-loaded with purpose, no redundancy. 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?

Simple tool with two string parameters and no output schema. Description covers all relevant aspects: purpose, usage, behavioral traits, and inter-tool relationships.

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 adds example keys and values, clarifying the semantic intent beyond the schema types.

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

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

Description uses specific verbs ('Save data') and resources ('key-value pair'), lists concrete use cases (resolved ticker, target 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 states when to use ('when you discover something worth carrying forward') and mentions pairing with recall/forget. Does not provide negative examples but gives clear 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 provided, the description carries the full burden. It discloses that the tool returns identifiers and pipeworx:// citation URIs, and suggests it is a read-only lookup. It does not mention auth or rate limits, but the examples and purpose imply safe, non-destructive behavior. The explanation of IDs is adequate for a lookup 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 (3 sentences) and well-structured. The first sentence states the core purpose, followed by examples and a usage tip. Every sentence adds value; no wordiness.

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 briefly but sufficiently covers return values (IDs and citation URIs). It also provides context on efficiency by stating it replaces multiple lookup calls. For a tool with 2 simple params, this is complete and actionable.

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 descriptions. The description adds significant value by providing concrete examples for each parameter (e.g., 'AAPL', '0000320193', 'ozempic'). This goes beyond the schema's abstract 'string' type, helping the agent understand what valid inputs look like.

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 look up canonical identifiers for companies or drugs. It specifies the identifier systems (CIK, ticker, RxCUI, LEI) and provides concrete examples, making it easy to understand what the tool does. It also implicitly distinguishes itself from siblings by positioning it as a prerequisite for other tools needing official identifiers.

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

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

The description explicitly tells when to use this tool ('when a user mentions a name and you need the CIK...') and recommends using it before other tools that need official identifiers. It also indicates that it replaces multiple lookup calls, giving clear guidance on its role in a workflow.

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 discloses search scope and return fields but omits details like pagination behavior, rate limits, or auth requirements. Adequate but not exhaustive.

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 action. Concise but slightly crowded; could be improved by splitting into bullet points for readability.

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

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

Good overview of search scope and fields, but lacks details on response format. Given no output schema or annotations, description is fairly complete for a search 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 each parameter is documented. Description adds general context but does not enhance individual parameter meanings 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 verb 'search', resource 'French legal units', and specifics on match fields and return values. Distinguishes from siblings like resolve_entity or entity_profile which are more specific lookups.

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?

Implies usage for free-text search across multiple criteria, but no explicit guidance on when to use this vs. sibling tools, nor exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: returns a verdict, extracted form, actual value with citation, and percent delta. It also states it replaces multiple sequential calls. Although not explicitly stating 'read-only', the nature of fact-checking implies no destructive side effects. The description adequately explains what the tool does and its 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 concise with 6–7 sentences. It is front-loaded with the main purpose, then usage, then specifics. Every sentence adds value without fluff. 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 has 1 parameter, no output schema, and no annotations, the description covers all necessary context: purpose, usage, return values (verdict types), limitations (v1 scope), and efficiency benefits. It is complete enough for an agent to decide when to invoke and what to expect.

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% (1 parameter with a description). The description adds value beyond the schema by constraining the claim to company-financial topics for v1, which is not in the schema. This extra context helps agents understand valid inputs.

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

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

The description clearly states the tool's purpose: fact-check, verify, validate natural-language factual claims against authoritative sources. It specifies the verb (validate) and resource (claim), and explicitly defines the scope (company-financial claims for US public companies via SEC EDGAR + XBRL). This distinguishes it from sibling tools like ask_pipeworx, which is likely general Q&A.

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 guidance with examples (e.g., 'Is it true that…?'). It also specifies the v1 limitations (only company-financial claims). However, it does not explicitly mention when NOT to use or suggest alternative tools among siblings.

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