HSH Data-on-Demand

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

Given no annotations, the description provides good behavioral context: SMTP-validated emails, bounce rate <3%, and per-record pricing with quantity tiers. It does not cover latency, rate limits, or authorization, but overall is sufficient.

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 brief and front-loaded with key information: what the tool provides, quality assurance, filters, and pricing. 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?

For a tool with 4 parameters and no output schema, the description covers core functionality, data quality, filters, and pricing. However, it does not specify the return format (e.g., array of objects), which would be helpful.

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% (all parameters described in schema). The description does not add additional meaning to individual parameters beyond what the schema provides, 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 the tool provides verified B2B contact records with name, business email, company, and mentions SMTP validation and pricing. However, it does not explicitly differentiate from sibling tools like hsh-b2b-enriched or hsh-b2b-full.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions pricing tiers and filters but does not advise on context or exclusions for using this over other B2B 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 mentions data enrichment and pricing tiers but lacks disclosure of important behavioral traits such as rate limits, authentication requirements, idempotency, or whether the tool performs a search or purchase. The pricing info is useful but incomplete.

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 key information about the tool's outputs and pricing. It is efficient with no filler, though it could be more structured (e.g., bullet points) for 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 the tool has 5 parameters, no output schema, and no annotations, the description provides partial completeness: it outlines return fields and pricing tiers but omits details on how to specify 'role' and 'industry', the ordering process, and potential costs beyond the tiers. More context needed for safe 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?

The input schema has 5 parameters with only 40% coverage (seniority and company_size have descriptions). The description adds meaning for 'quantity' by linking it to pricing tiers, but fails to explain 'role' and 'industry' parameters. Thus, it partially compensates for schema gaps but not fully.

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 provides multi-source enriched B2B records including name, email, LinkedIn URL, title, company size, and industry, with cross-referencing from 3+ sources. This differentiates it from siblings like 'hsh-b2b-contact' and 'hsh-b2b-full'.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'hsh-b2b-contact' or 'hsh-b2b-full'). No when-to-use or when-not-to-use instructions are present, leaving the agent to infer 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions pricing tiers (cost) but does not state whether the tool is read-only, destructive, or has rate limits, authentication needs, or other safety characteristics. The description is insufficient for an agent to understand side effects.

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

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

The description is concise (4 sentences) and front-loads the main offering ('Deep enrichment: ...'). Pricing info is secondary but relevant. No wasted words, though the structure could be improved by separating functional description from pricing.

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 complexity (5 parameters, no output schema), the description is incomplete. It does not explain what the tool returns beyond a list of data types, how to use parameters effectively, or ordering/filtering behavior. Without an output schema, the agent cannot understand the response format, making it inadequate for a tool of this depth.

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 low (20%): only tech_stack has a description. The description lists data points (name, email, phone, etc.) but these are not parameters—parameters are industry, quantity, tech_stack, funding_stage, revenue_range. It does not explain industry, funding_stage, or revenue_range, nor does it add meaning beyond the schema. The description fails to compensate for missing 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 this is a 'deep enrichment' tool that returns multiple data types (name, email, phone, LinkedIn, firmographic, tech stack, funding, revenue). It mentions multi-source fusion, which distinguishes it from simpler tools. However, it does not explicitly differentiate from siblings like hsh-b2b-contact or hsh-b2b-enriched, leaving some ambiguity.

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 says 'For sales teams that need everything,' implying use when comprehensive data is required. But it lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives or exclusions. The context is clear but not directive.

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 must fully disclose behavior. It explains the warm/fresh inventory check but is ambiguous about whether it returns an actual fulfillment or just a quote. It omits side effects, permissions, rate limits, and error handling, leaving significant gaps.

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

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

Two sentences with no wasted words. The first sentence defines the action, the second adds usage guidance. It is well front-loaded and 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?

While the description covers the core workflow, it lacks details on output format, error cases, and what happens when no inventory is found. Without an output schema or annotations, the agent may be left guessing about the response structure.

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 marginal value by explaining the 'need' parameter as 'plain-language' and 'keywords' with examples, but does not go beyond the schema descriptions.

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

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

The description clearly states the tool routes data needs through HSH and explains the warm vs fresh fulfillment distinction. It differentiates from sibling tools by positioning itself as a generic routing tool, though it could be more explicit about when to use specific siblings.

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

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

The description provides clear usage context: 'Use this when you need data mid-task and want HSH to fulfill it.' However, it lacks explicit guidance on when not to use it or references to alternative tools for specific data types.

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 notes the tool is free and checks status, but fails to disclose behavioral traits such as what happens if the order is not found, rate limits, or data freshness. This is minimal disclosure for a 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?

The description is extremely concise at one sentence plus 'FREE.', with all information front-loaded. Every word earns its place without superfluous text.

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

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

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers core functionality and parameter format. It could mention the return behavior for missing orders, but overall it is adequately complete for a straightforward lookup tool.

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

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

Schema coverage is 100% with one parameter 'order_ref' described as 'The order reference, e.g. HSH-1A2B3C4D'. The description adds the pattern 'HSH-XXXXXXXX' but adds minimal value beyond the schema, 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 verb 'Check' and the resource 'fulfillment status of a paid order', using the required order reference format 'HSH-XXXXXXXX'. It distinguishes this tool from siblings like 'hsh_check_quote' and 'hsh_check_subscription' by specifying it is for order fulfillment.

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

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

The description indicates the tool is free and shows the expected order reference format, implying usage when you have a paid order. However, it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool is free and returns specific fields (status, frozen price, expiry, pay_url). It gives a clear behavioral picture without 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 a single, concise sentence of 14 words. Every word adds value, and it is appropriately 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 simple tool with one parameter and no output schema, the description adequately explains the purpose, return values, and source of the input. It is complete enough for an agent to use correctly.

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

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

The schema has 100% coverage for the single parameter, with a description providing an example. The tool description adds context by noting the parameter comes from hsh_describe_data_need, enhancing semantic meaning beyond the schema.

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

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

The description clearly states the verb 'Check' and the resource 'quote_ref', and specifies the returned information (status, frozen price, expiry, pay_url). It distinguishes the tool from siblings like hsh_check_order and hsh_check_subscription by its unique focus on quotes.

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

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

The description implies that the tool should be used after obtaining a quote_ref from hsh_describe_data_need, but it does not explicitly state when to use it versus alternatives or provide exclusions. The guidance is implied rather than explicit.

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 must carry full burden. It only states the basic purpose and return fields, without disclosing side effects, auth requirements, rate limits, or error conditions. 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?

The description is a single sentence, front-loaded with 'FREE', and efficiently covers purpose, input format, and return fields without 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?

With no output schema, the description explains return values (watching, status, match criteria) and input format. Lacks examples or error handling, but for a simple check tool with one param, it is mostly complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds the format hint '(HSHSUB-XXXXXXXXXX)' and the schema includes an example. No further semantics added 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 verb 'Check' and the resource 'subscription', and specifies what it returns: 'what it's watching, status, and match criteria'. It distinguishes from siblings like hsh_check_order or hsh_check_quote.

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

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

The description implies usage for checking a subscription via sub_ref but does not explicitly state when to use or avoid it, nor mention alternatives. The 'FREE' tag might hint at cost but not 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 discloses key behaviors: real-time nature, return data fields, lookup vs discover modes, and payment mechanism. It does not mention rate limits, error handling, or data freshness, but covers essential aspects for a data retrieval tool.

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

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

Three concise sentences, front-loaded with purpose, then listing return fields and modes. No redundant information. Every sentence provides necessary context.

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

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

Given no output schema and 4 parameters (including nested filters), the description explains the two modes, return fields, and cost. It lacks details on output format or pagination but is largely sufficient for an agent to understand when and how to use 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 description coverage is 50% (query and filters described, mode and limit have empty descriptions). Description compensates slightly by naming the two modes and implying limit usage, but does not fully document all parameters. It adds some meaning beyond schema but not enough.

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

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

Description clearly states the tool provides real-time intelligence on startups/companies, lists specific data returned (profile, founders, tech stack, hiring signals, YC batch), and distinguishes between lookup and discover modes. This differentiates it from sibling tools like hsh-crypto-intel or hsh-b2b-contact.

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 explains two usage modes (lookup for one company, discover for filtered list) and mentions pay-per-call cost. However, it does not explicitly state when to use this tool over siblings or provide exclusions for certain use cases.

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

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

No annotations are provided, so the description carries full burden. It discloses 'pay per call via x402' (a behavioral trait) and describes the grading from historical data, implying a read-only operation. However, it does not explicitly confirm non-destructive behavior or mention any rate limits or permissions, leaving some gaps.

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

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

The description consists of two concise sentences. The first sentence front-loads the core purpose and output, and the second adds cost information. Every part is necessary and no words are wasted.

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

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

The tool is simple (1 parameter, no output schema). The description explains the output range (Easy to Very Hard) and data source (historical chase-success data), and includes cost info. However, it could be more precise by listing the exact possible grades or stating the return type (string), making it slightly incomplete.

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 parameter 'target' described as 'The target to be chased.' The description adds no extra meaning beyond the schema, such as units (runs) or format constraints. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states it's a chase difficulty rating at innings break, grading from Easy to Very Hard based on historical data. It uses a specific verb 'grades' and resource 'chase difficulty rating', distinguishing it from sibling tools like hsh-cricket-chase-winprob (win probability) and hsh-cricket-first-winprob (first innings win probability).

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

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

The description implies usage at the innings break, but does not explicitly state when to use this tool versus alternatives (e.g., chase-winprob for probability instead of difficulty). No when-not-to-use or comparison to siblings is provided, only implicit 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions 'Real-time' and 'updated per ball' and model performance stats, but lacks details on limitations, data sources, or what the output represents (e.g., probability value range).

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

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

Three sentences front-loaded with purpose. Second sentence adds model quality context which may not be essential for tool invocation but is not excessive.

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

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

The tool has 4 numeric parameters with full schema coverage, no output schema, and no annotations. The description is adequate for a simple calculation tool but lacks details on return format, error handling, or prerequisites beyond the 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 coverage is 100%, meaning all parameters are well-documented in the schema. The description does not add any extra semantics beyond the schema, thus baseline score of 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 it computes real-time chase win-probability for T20 cricket. However, sibling tools like hsh-cricket-chase-difficulty and hsh-cricket-first-winprob exist, and the description does not differentiate this tool from them.

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?

Mentions 'In-play betting signal' hinting at use case, but no explicit guidance on when to use this versus alternatives, nor any conditions 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?

With no annotations provided, the description carries the full behavioral burden. It discloses key behaviors: ranks players by fantasy value, selects optimal captain with a 35.6% hit rate (2x random), and mentions x402 payment. This is valuable beyond the schema, though it could be more explicit about result format or side effects.

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

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

The description is concise (three sentences) and front-loaded with the tool's primary purpose. Every sentence adds value: purpose, unique selling point (captain hit rate), and pricing model. No extraneous information.

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

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

Given moderate complexity (3 parameters, no output schema), the description lacks information about the return format or structure of the picks and captain result. It also does not explain how venue or is_chase affect predictions. This gap reduces completeness for an agent needing to interpret results.

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

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

Schema coverage is 100% with clear descriptions for all parameters (venue, players, is_chase). The tool description adds minimal extra meaning beyond the schema, only noting 'Dream11-style' and captain selection. Baseline 3 is appropriate as schema already provides sufficient detail.

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 provide fantasy cricket picks and optimal captain for a T20 match, ranking players by predicted value. It distinguishes itself from sibling cricket tools (e.g., hsh-cricket-form, hsh-cricket-chase-difficulty) by focusing specifically on fantasy selection, making the verb+resource pairing highly 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 implies usage for Dream11-style fantasy cricket but does not explicitly state when to use this tool versus alternative sibling tools. No when-not conditions or prerequisites are provided. The mention of 'Pay per call via x402' gives some usage context but lacks definitive 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?

No annotations provided; the description adds some context (AUC 0.76, venue + team strength, pay per call) but does not disclose mutation or side effects. Since the tool is read-only, this is acceptable but minimal.

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 very short (one sentence plus cost note) and front-loads purpose. It loses a point for not separating cost or model accuracy into a clear structure.

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 6 parameters (3 required) and no output schema or annotations, the description fails to explain required parameters and output, leaving significant gaps for correct 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 description coverage is 0%; the description only mentions 'venue + team strength' without linking to specific parameters. Required parameters like balls_bowled, wickets, cum_runs are not explained.

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

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

The description clearly states the tool computes first-innings win probability for a team setting a total, using venue and team strength. It distinguishes from sibling tools like chase-winprob.

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

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

The description implies usage for first innings but does not explicitly state when to use or when not to use, nor does it mention alternatives like chase-winprob.

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 should disclose behavioral traits like return format, data freshness, or error handling. It only mentions 'Pay per call via x402' which is a billing note, not behavioral. No description of output structure or side effects.

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

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

The description is concise (two sentences) and front-loaded with the main purpose. Every phrase adds value without unnecessary detail.

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

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

For a simple tool with one parameter and no output schema, the description covers core functionality, target audience, and a use case. It is mostly complete but could benefit from indicating return format or update frequency.

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

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

The schema already describes the parameter with a note on partial matching. The description adds that the tool is for 'established IPL players,' providing context on the target demographic, which adds semantic value beyond the schema.

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

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

The description clearly states the tool provides player form and fatigue ratings for IPL players, with specific outputs like hot/cold form and bowling-workload fatigue flag. While not explicitly distinguishing from siblings, its focus on form/fatigue is distinct within the cricket domain.

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 mentions 'Fantasy signal' as a use case, but does not provide explicit guidance on when to use this tool versus other cricket tools (e.g., chase difficulty, matchup analysis) or when it would be inappropriate.

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

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

With no annotations, the description discloses pricing ('Pay per call via x402'), data quantity (111K pairs), and Bayesian adjustment. It implies a read-only query by describing output fields, but does not explicitly state side effects or safety profile. Overall provides useful 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?

Two sentences, no wasted words. The first sentence covers data and scope, the second sentence covers use case and billing. Efficient and 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 and no annotations, the description adequately explains output fields and usage context. It could elaborate on the dominance score calculation, but for a simple lookup tool 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?

Input schema covers parameters fully with descriptions (e.g., 'partial match ok'). The tool description does not add additional parameter details beyond what schema provides, so baseline score of 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?

The description clearly states it provides batter-vs-bowler head-to-head records with specific data (balls, runs, dismissals, dominance score) and use cases (fantasy, in-play). It distinguishes itself from sibling cricket tools by focusing on head-to-head matchup statistics.

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 mentions 'Fantasy + in-play edge,' indicating usage context. However, it does not explicitly state when not to use or provide alternatives among siblings, though the purpose is clear enough for agents to infer.

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, placing the full burden on the description. The description discloses the output (momentum and pressure index) but fails to mention any behavioral aspects such as data freshness, rate limits, side effects, or whether results are real-time or delayed. The cost note is helpful but insufficient.

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

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

The description is concise at two sentences, front-loaded with the primary purpose. It efficiently conveys the core functionality without redundancy. However, it could benefit from slight restructuring to include output expectations.

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 lack of an output schema, the description should explain the return format or structure of the momentum and pressure index. It only provides high-level terms without specifying whether output is numeric, textual, or includes additional metadata. The tool involves nested input objects, yet no guidance on data types or example usage is given.

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 all parameters described in the schema (target, prev, curr). The description adds no additional meaning or constraints beyond what the schema already provides, resulting in a 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 the tool's function: calculating momentum and pressure index for a live T20 chase. It uses specific terms like 'swing signal' and 'pressure score', and identifies it as an 'in-play trader signal', distinguishing it from sibling cricket tools like chase difficulty or win probability.

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?

While the description implies use for in-play trading and mentions cost ('Pay per call via x402'), it does not explicitly state when to use this tool over alternatives like hsh-cricket-chase-winprob or hsh-cricket-timeline. No exclusion criteria or context for selection is provided.

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 partially compensates by revealing accuracy, comparison to naive extrapolation, and pay-per-call pricing ('x402'). However, it does not disclose behavioral traits such as input constraints (e.g., valid ranges), rate limits, or non-destructive nature. The pricing model is a useful disclosure 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?

Three sentences, front-loaded with purpose. The accuracy comparison and betting signal are relevant but could be considered slightly verbose. Overall, it is efficient and avoids 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 4 parameters, the description lacks critical details: output format (e.g., return value type, units), input validation rules, and start-of-innings behavior. The pricing model is noted, but the tool's usage context for betting implies a need for more precise behavioral specification.

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 0% and the description provides no additional meaning for the parameters (venue, wickets, cum_runs, balls_bowled). While parameter names are somewhat self-explanatory, the description does not explain their roles, constraints, or formatting, leaving the schema entirely uninformative.

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 projects a par score or first-innings total from a mid-innings state. It differentiates itself with accuracy claims ('accurate to +/-8.6 runs') and a betting signal use case, but does not explicitly distinguish from sibling cricket tools like chase difficulty or win probability.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention of 'over/under betting signal' implies a specific use case, but there is no direction on prerequisites, exclusions, or context where other tools would be preferred.

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 must bear full burden. It discloses that the tool is paid and broadcast-quality, but fails to specify output format (e.g., JSON structure), data freshness (real-time vs. historical), or any side effects. The phrase 'the broadcast worm' hints at a common visualization but does not clarify what the tool returns.

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 lines, front-loaded with the core purpose and key differentiators (broadcast-grade, pay-per-call). Every sentence adds value without redundant information. One minor point: the second sentence could be merged for smoother flow, but it remains clear and 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?

With no output schema and only 2 parameters, the description is insufficiently complete. It explains the input format (events per over) but omits the output format (e.g., array of probabilities, percentage values). Users cannot fully understand what the tool returns without additional inference.

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 50% with 'target' having an empty description. The tool description adds context by defining 'events' as per-over states and implying 'target' is the chase target. However, it does not fully compensate for the missing parameter documentation; more detail on the expected format for 'target' would improve utility.

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 provides an 'over-by-over win-probability timeline' for a 'full T20 chase', using the familiar 'broadcast worm' analogy. This specific verb+resource combination distinguishes it from sibling tools like hsh-cricket-chase-winprob or hsh-cricket-chase-difficulty, which infer aggregate or pre-chase probabilities.

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

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

The description implies usage for broadcast/media purposes ('Media/broadcast-grade') and mentions payment ('Pay per call via x402'), but does not explicitly state when to use this tool over alternatives such as hsh-cricket-chase-winprob or hsh-cricket-first-winprob. No when-not-to-use conditions or alternative tool names are provided.

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 payment via x402 and the three layers, but lacks details on authentication, rate limits, data freshness, or error handling. It does not contradict any 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 three sentences, front-loads the purpose, then lists layers, payment, and supported assets. Every sentence adds value with 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 the complexity of returning three layers of intelligence and no output schema, the description covers the high-level functionality well. It could benefit from mentioning the output format, but the provided details are sufficient for initial tool selection.

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%, providing baseline of 3. The description adds value by enumerating supported assets ('BTC, ETH, SOL, BNB, XRP, DOGE'), which goes beyond the schema's example. It adds meaning without repeating schema details.

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

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

The description states 'Complete crypto intel for trading agents' with a clear verb-resource combination. It distinguishes itself from siblings by being the only crypto-specific tool among many non-crypto tools, and it explicitly lists the three layers of intelligence provided.

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 implicitly tells when to use this tool (when needing crypto intel across positioning, on-chain, liquidation risk) and mentions the pay-per-call model. However, it does not explicitly state when not to use or compare to alternative 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, the description carries the full burden. It discloses setup fee, per-record cost, and includes parser dev, QA, and documentation. But it lacks details on turnaround time, data sourcing process, or limitations, making transparency average.

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 relatively concise, containing two sentences plus pricing and tier information. Every sentence adds value, though it could be slightly more structured 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?

For a custom dataset creation tool with no output schema, the description provides pricing and effort scope but misses process details (e.g., how results are delivered, turnaround time, whether it's a one-time or subscription). It is incomplete for a task of this complexity.

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

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

Schema coverage is 50% (schema_description and sources_hint have descriptions, delivery_format and quantity_estimate do not). The description elaborates on schema_description ('Plain English description') and hints at delivery format implicitly, but does not fully compensate for the undocumented parameters.

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 creates novel custom datasets (cross-domain fusion, industry-specific schemas, real-time aggregated intelligence). It distinguishes itself from sibling tools that presumably offer pre-existing datasets.

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 context on when to use (novel datasets not existing elsewhere) and includes pricing tiers (Tier 3 for small builds, Tier 4 for novel/large) which helps guide usage. However, it does not explicitly state when not to use or list alternatives.

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

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

Discloses that the tool is free, provides an instant firm quote with price in USDC, scope, quote_ref, and pay_url, and explains payment via x402 and 24h delivery. Since no annotations exist, description carries full burden and meets it well.

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 with front-loaded key info (free, quote details). No wasted words, each sentence adds essential 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 3-param tool with no output schema, description sufficiently explains input expectations, output format (price, scope, quote_ref, pay_url), and process (pay to order, delivery in 24h). Covers agent's needs for correct 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%, but description adds clarifying examples for 'need' (type, volume, geography, freshness) and indicates budget may be accepted within a floor, adding value beyond schema defaults.

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 ('describe data need', 'receive quote') and clearly identifies the resource (a firm quote). Distinguishes from siblings by positioning as a pre-purchase quote tool, unlike specialized data 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 'Use this BEFORE purchasing custom data.' Provides clear context but does not explicitly list when not to use or alternative 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, so description bears full burden. Discloses data source (SEC filings), event mapping, severity grading, and links. Mentions payment per call. Does not discuss rate limits or idempotency, but these are less critical for a read-only 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?

Single paragraph with dense, relevant information. Every sentence adds value. Could be slightly more structured with bullet points, but no redundancy.

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

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

No output schema but description explains return structure: events mapped to pillar, severity-graded, with links to SEC filings. Covers source, event types, filtering options. Complete for a data retrieval 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 covers all parameters (100% coverage) with clear descriptions. Tool description adds no additional detail for parameters beyond what schema provides. 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?

Clearly states it provides authoritative company-attributed ESG material-event intel for US-listed companies from SEC filings. Specific verb ('provide'), resource ('ESG events'), and source (SEC EDGAR). Differentiates from siblings like hsh-esg-news by specifying the source and nature.

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?

Describes filtering options (ticker, pillar) and payment model but does not explicitly state when to use this tool over alternatives like hsh-esg-news or other data tools. Lacks guidance on when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses behavioral traits: real-time detection, enrichment with GLEIF entity resolution and EU sanctions screening, pillar classification, severity grading, source linking, and payment via x402 (USDC on Base). It implies read-only behavior without destructive actions. Could mention potential data latency or rate limits but is sufficient.

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-loading the purpose and key features. Two sentences plus a few fragments cover purpose, region filter, sibling complement, and payment method with 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, the description mentions 'Pillar-classified, severity-graded, source-linked' to hint at return format, but lacks explicit structure, pagination details, or error handling. For a tool with enrichment, more detail on output fields would improve completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context like the region filter and optional company filter, but does not significantly expand on the schema's existing descriptions. For instance, 'limit' is already described as 'Max controversies to return.' The description reiterates 'pass region='EU'' which aligns with 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 'EU & global ESG controversy intel for compliance and trading agents' and specifies detecting ESG controversies from news, enriching with LEI and sanctions screening, and pillar classification. It distinguishes from sibling hsh-esg-events by mentioning 'News-derived breadth (complements the authoritative SEC-filing ESG product hsh-esg-events)'.

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 specific guidance on when to use (e.g., real-time news vs SEC filings) and a direct instruction: 'Pass region='EU' to filter to EU-domiciled companies.' It also names the sibling alternative hsh-esg-events. However, it does not explicitly state when not to use the tool.

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

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

With no annotations provided, the description covers key behavioral traits: delivered as a cleaned, HuggingFace-ready dataset in Alpaca schema, deduplicated, with train/val/test split and programmatic verification. It also mentions pricing tiers and a sample. However, it omits details on processing time, synchronous/asynchronous behavior, or limitations (e.g., maximum row count beyond stated tiers).

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, somewhat lengthy paragraph (~120 words). It front-loads the core purpose (first sentence) but includes extra details like pricing tiers and a sample link that, while useful, could be condensed. It is not overly verbose but could be more structured (e.g., bullet points) to improve scanability.

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 (custom dataset creation with verification) and lack of output schema, the description provides sufficient context: what the dataset contains, the schema, verification method, splitting, and pricing. It also gives a concrete example. However, it could be enhanced by specifying turnaround time or limitations (e.g., data size caps).

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 6 parameters are documented in the input schema (100% coverage), so baseline is 3. The description adds overarching context (e.g., default schema, verification approach, pricing) but does not provide additional per-parameter details beyond what the schema already gives. Thus, the description adds some value but not enough to raise the score.

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

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

The description clearly states the tool creates 'made-to-order, answer-verified datasets for LLM fine-tuning', specifying the output format (Alpaca schema), verification method, and sample availability. This distinguishes it from siblings like hsh-custom-dataset by emphasizing verification and tailored dataset construction.

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

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

The description provides clear context for when to use the tool (for fine-tuning tasks needing verified datasets) and includes examples of applicable tasks. However, it does not explicitly state when not to use it or mention alternative tools, which would be helpful for differentiation.

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 fully carries the transparency burden. It details each signal's source (e.g., SEC Form 4, GitHub stars), derivation (e.g., hiring posture from department mix), and timeframes (e.g., last 90 days). It also notes the predictive nature ('precede price moves') and payment method.

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

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

The description is front-loaded with the core purpose and then enumerates signal details in a numbered list. While lengthy, each sentence provides necessary context. Could be slightly more concise but well-structured for the complexity.

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

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

The description explains inputs and signals thoroughly but omits output format or structure. Given no output schema, the agent lacks guidance on what the response contains (e.g., is it a single score, individual signals, or a report?). This gap reduces 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 schema covers all 9 parameters with descriptions. The description adds context by grouping them into signals (e.g., 'hiring posture across Greenhouse + Lever + Ashby') and explaining usage (e.g., 'Hacker News search term'). This adds value beyond the schema but not extremely detailed.

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 provides multi-signal alt-data intel for investment research, listing six distinct signals. It distinguishes from sibling tools by offering a composite of hiring, insider, GitHub, Wikipedia, App Store, and Hacker News signals in one call.

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 to 'Pass whichever identifiers you have,' implying flexibility and partial usage. It mentions payment via x402, hinting at cost awareness, but does not explicitly contrast with single-signal tools or state when not to use.

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

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

No annotations are provided, so the description fully bears the burden. It discloses real-time, pay-per-call nature, classification by event type, and sentiment tagging. It does not mention rate limits or data freshness details, but the key behavioral traits are adequately covered.

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, front-loaded with the core purpose, and every sentence adds value. There is no fluff or repetition, making it highly 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?

No output schema exists, but the description explains the return format: announcements classified by event type, sentiment, and impact summary. This is fairly complete given the tool's purpose. Minor gaps like pagination or maximum limit are acceptable for real-time data.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining 'limit' as 'how many recent announcements' and 'symbol' as 'Optional NSE symbol filter', complementing the schema descriptions with clarity on 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?

The description clearly states it provides 'Live NSE corporate-announcement intel' for Indian companies, with specific event types listed. The verb 'intel' implies data retrieval, and the resource is announcements, distinguishing it from sibling tools like hsh-india-fundamentals.

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

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

The description implies the tool is for fetching corporate announcements with optional symbol filter, but does not explicitly state when to use it versus alternatives (e.g., for fundamental data vs announcements). No exclusions or prerequisites are 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, so description carries full burden. It discloses data source, frequency (quarterly/annual), units (INR crore), and cost mechanism. However, it does not mention rate limits, idempotency, or response size limits.

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

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

Description is a single dense block but front-loads the main purpose and uses clear listing. Every sentence adds value, though could be structured with 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?

No output schema, so description must explain return values. It does so in detail covering P&L, balance sheet, ratios, shareholding, and units. Missing error handling or symbol validation, but overall comprehensive for a fundamentals 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%, but description adds value by explaining 'Pass an NSE symbol' and giving examples (RELIANCE, INFY), and clarifies period values 'Quarterly or Annual.' This exceeds the baseline of 3.

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

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

Description clearly specifies the tool provides Indian listed-company fundamentals from NSE XBRL filings, listing exact data categories (P&L, balance sheet, ratios, shareholding). Distinguishes from siblings by its focus on fundamentals and regulatory source.

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?

States to pass an NSE symbol and notes pay-per-call, but does not explicitly guide when to use this vs. alternative tools like hsh-india-announcements. Usage context is implied but lacks explicit when/not recommendations.

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 must carry full burden. It mentions 'FREE' and 'live pricing' but does not disclose return format, pagination, or potential side effects. For a list-only tool, this is minimal but acceptable; however, without annotations, it lacks depth.

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 focused sentence with no wasted words. It front-loads the key purpose and includes important context about pricing and ordering. Highly 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?

For a tool with no parameters and many siblings, the description covers core purpose but omits details like output structure or authentication needs. It is not fully self-contained given the absence of 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?

There are zero parameters, so baseline is 4. The description does not add parameter information because none exist. No deduction needed.

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 lists HSH Intelligence's catalogued data capabilities with live pricing and instructions for ordering custom data. The verb 'list' and specific resource make the purpose unambiguous.

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

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

No explicit guidance on when to use this tool versus siblings. The 'FREE' prefix hints it's safe for exploration, but no alternatives or when-not-to-use advice is provided.

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 cost (Pay per call via x402), data sources, and limitations (deep financials not available). However, it lacks details on authentication, rate limits, or any side effects of queries.

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 relatively long but well-structured: it starts with a clear one-line summary, then breaks down the data components. Every sentence adds value, but it could be slightly more concise without losing 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?

Given the absence of an output schema, the description does a good job of explaining the output structure (oil prices, macro data, equity prices, etc.) and limitations. It is comprehensive for a tool with only two optional parameters.

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?

Although the schema already covers both parameters with descriptions, the tool description adds significant context by explaining how the country and ticker influence the output (e.g., Saudi adds Tadawul data) and providing concrete examples of ticker formats.

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

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

The description clearly identifies the tool as providing MENA (Gulf) market intelligence for trading agents, with specific data points (oil, macro, USD-peg, equities) and a mention of Saudi-specific Tadawul data. This distinguishes it from sibling tools like hsh-crypto-intel or hsh-company-intelligence.

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 to pass a country code and optional ticker, and notes that for Saudi data, Tadawul API is used. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusion criteria or prerequisites.

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 mentions features and pricing but omits behavioral traits like rate limits, error handling, data retention, or whether changes are destructive.

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-loaded with purpose, no fluff—pricing is relevant for selection but concise.

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; description lacks details on how results are returned, cancellation, authentication, limits—critical for a monitoring service given its ongoing nature.

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 40%; description adds context for frequency (real-time mentioned but not in enum) and pricing linked to duration_months, but webhook_url and alert_threshold remain unclear.

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 monitors URLs for changes with options for frequency, webhook alerts, and screenshots, distinguishing it from siblings like hsh-web-scrape (one-time scrape).

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

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

The description implies usage for continuous monitoring but lacks explicit guidance on when to use versus alternatives, no prerequisites or exclusions.

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

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

No annotations provided, so description carries full burden. It discloses the output (verdict with failing test and ratios) and payment model, but lacks details on data freshness, rate limits, or authentication.

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

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

Three sentences, each serving a purpose: purpose definition, screening criteria, and output/payment. No redundancy or unnecessary details.

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

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

Explains methodology, output, and payment. Missing minor details like data update frequency or whether the screener is real-time. Still fairly complete 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?

The single parameter 'ticker' has a schema description with examples (AAPL, XOM, JPM) and context of US-listed. This adds value beyond the schema, which already provides type and required status.

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 is a Shariah compliance screen for US-listed companies, detailing the screening criteria (business-activity and financial ratios). This distinguishes it from sibling tools, none of which offer shariah screening.

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?

Implied usage for shariah compliance screening of US equities. No explicit when-to-use vs alternatives or when-not-to-use. The payment note is a requirement, not a guideline.

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 burden. It discloses that the tool is free to set up and pay-per-delivery via x402, and that it sends a quote on match. However, it omits details on subscription lifecycle, cancellation, and what happens when no match occurs.

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 fairly concise, front-loading the key value proposition and using a few sentences. It could be more structured but avoids unnecessary 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 the 6 optional parameters and no output schema, the description provides the overall concept but doesn't explain the full workflow, such as how to manage subscriptions or what responses look like. It lacks references to sibling polling functions.

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 each parameter having a clear description. The tool description adds minimal extra meaning beyond the schema, providing context but not further clarifying parameter 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?

The description clearly states the tool's purpose: registering a standing subscription to monitor events (e.g., SEC filings) and receive quotes on match, turning one-off purchases into an always-on feed. It distinguishes from siblings by emphasizing the subscription aspect.

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

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

The description implies use for continuous monitoring rather than one-off buys but lacks explicit when-to-use or when-not-to-use comparisons with siblings like hsh_check_subscription. No alternatives or exclusions are 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?

Discloses handling capabilities and pricing tiers, but lacks details on rate limits, authentication, error handling, or legal considerations.

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

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

Three sentences, front-loaded with purpose. Pricing details add length but are relevant. 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?

Lacks details on supported output formats, turnaround time, and limitations. Given the complexity of web scraping and no output schema, more completeness would be beneficial.

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

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

Schema covers all parameters with descriptions; the tool description adds context on complexity multipliers and tiers, but doesn't significantly enhance parameter meaning.

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

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

Description clearly states extracting structured data from public sites, handling various page types. Distinguishes from sibling tools focused on specific datasets.

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

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

No explicit guidance on when to use this vs. alternatives like pre-built datasets. Pricing info is useful but doesn't clarify selection criteria.

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