HSH Data-on-Demand

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

The description adds behavioral context like SMTP validation, low bounce rate, and pricing tiers. However, it lacks information about data freshness, accuracy guarantees beyond bounce rate, or any potential limitations. No annotations are provided, so the description carries full burden.

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) with front-loaded main offering. Every sentence adds value: what you get, quality, filters, pricing. No fluff.

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

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

Given no output schema, the description covers inputs, output type (name, email, company), quality, and pricing. Lacks details on return format, pagination, or error handling, but is fairly complete for a data purchase 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 parameter descriptions. The description adds context by mentioning 'Industry/title filters' corresponding to role/industry parameters and pricing tiers for the quantity parameter, providing additional 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 it provides verified B2B contact records with name, business email, and company, and mentions filters and pricing. However, it does not differentiate from sibling tools like hsh-b2b-enriched 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?

No guidance on when to use this tool vs. alternatives such as hsh-b2b-enriched or hsh-b2b-full. No when-to-use or when-not-to-use information.

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

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

The description mentions cross-referencing from 3+ sources for accuracy, which is positive, but lacks disclosure of limitations, destructive actions, or behavior under edge cases (e.g., no results, rate limits). No annotations are present to compensate.

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

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

The description is concise, with two sentences covering core value and accuracy. The pricing tiers add context but could be moved to a separate annotation. Overall, minimal waste and easy to scan.

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 5 parameters, the description lacks information on return format, error handling, pagination, or scaling behavior. The pricing tiers hint at quantity limits but are insufficient for a complete understanding of tool behavior.

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?

With only 40% schema description coverage, the description should clarify parameter use, but it only lists general fields (name, email, etc.) without mapping to input schema properties like role, industry, or quantity. The meaning and constraints of each parameter 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 the tool provides enriched B2B records with fields like name, email, LinkedIn URL, and cross-referencing for accuracy. However, it does not differentiate from sibling tools such as hsh-b2b-contact or hsh-b2b-full, leaving the agent uncertain about when to use this specific variant.

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

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

No guidance is provided on when to use this tool versus alternatives. The pricing tiers do not clarify use cases (e.g., single lookup vs bulk enrichment). An agent would not know if this tool is appropriate for a given request without comparing to siblings.

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

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

No annotations are provided, so the description must disclose behavioral traits. It describes what data is fused (multi-source) but does not clarify whether the tool is read-only, destructive, or requires permissions. No mention of side effects, rate limits, or output format. The description leaves the agent uncertain about operational behavior.

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 brief (two lines) and front-loaded with key capabilities. However, it includes pricing tiers which are tangential and could distract from pure functional clarity. Structure is adequate but not efficiently organized.

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 (only 1 required), no output schema, and context signals indicating low schema coverage, the description should provide comprehensive context. It lists data outputs but does not explain how parameters filter results, the meaning of tiers, or return format. The description feels incomplete for effective agent invocation.

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

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

Schema description coverage is only 20% (only tech_stack has a description). The tool description mentions tech stack, industry, funding, and revenue in general terms but does not map clearly to the parameters (industry, funding_stage, revenue_range). It adds minimal semantic value beyond what the sparse schema provides, failing to compensate for the low coverage.

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

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

The description clearly states the tool provides deep enrichment including name, email, phone, LinkedIn, firmographic data, tech stack, funding, and revenue. It identifies the target audience (sales teams) and mentions multi-source fusion. However, it does not differentiate from siblings like hsh-b2b-contact or hsh-b2b-enriched, which could perform similar tasks with different scope.

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 comprehensive enrichment needs ('need everything'), and provides pricing tiers suggesting batch sizes. But it offers no explicit when-to-use or when-not-to-use guidance, nor does it compare with sibling tools. The context is present 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, but the tool is a simple status check, implying read-only behavior. The description adds that it's free and uses an order reference. However, it does not explicitly state that the tool does not modify any data or have side effects, which would be helpful for an AI agent.

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 that conveys all essential information: free, purpose, and parameter format. Every word earns its place; there is no redundancy or 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 tool's simplicity (1 required parameter, no output schema), the description covers the purpose and parameter well. A minor gap is the lack of information about the return value, but for a status check, an AI agent can infer a status string. Overall, it is largely complete for the context.

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

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

The input schema already describes the parameter 'order_ref' with a type and description, achieving 100% coverage. The tool description adds value by providing a concrete example (HSH-1A2B3C4D) and clarifying the format pattern, which helps the agent format the parameter correctly.

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 fulfillment status'), the resource ('paid order by order reference'), and provides the exact format example (HSH-XXXXXXXX). It distinguishes from sibling tools like hsh_check_quote, which check quotes, not orders.

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

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

The description explicitly says 'FREE' and gives the format for the order reference, making it clear when to use this tool (when you have a paid order reference). It could be improved by explicitly stating when not to use it (e.g., if you need a quote, use hsh_check_quote), but the purpose is sufficiently distinct from siblings.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the tool is free and returns status, frozen price, expiry, and pay_url. It does not mention read-only nature, error handling, or rate limits, but for a simple lookup this is adequate.

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

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

The description is a single sentence with all essential information. It front-loads 'FREE' and clearly states purpose and output, with no unnecessary words.

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

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

For a simple tool with one parameter and no output schema, the description covers the main return fields and cost. It lacks details on error cases (e.g., invalid quote_ref) or updates, but overall it provides sufficient context 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?

With 100% schema coverage, baseline is 3. The description adds value by specifying the origin of the quote_ref (from hsh_describe_data_need), which clarifies context beyond the schema's example format.

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', specifies the source (hsh_describe_data_need), and lists the returned fields (status, frozen price, expiry, pay_url). It distinguishes from siblings by defining its specific role in the workflow.

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

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

The description implies usage context: it checks a quote_ref obtained from hsh_describe_data_need. It mentions 'FREE', hinting at cost implications. However, it does not explicitly exclude use cases or provide alternatives among siblings.

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

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

With no annotations, the description carries the full burden. It discloses pay-per-call via x402 (USDC on Base) and 'real-time' data, but does not mention rate limits, data freshness guarantees, or any destructive behavior. The payment detail 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?

Two sentences cover the tool's purpose, returns, modes, and payment. No fluff, but the structure could be improved by separating functionality from payment into distinct paragraphs.

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 4 parameters, no output schema, and no annotations, the description covers core functionality and modes. However, it lacks details on the discover query syntax, return format, error behavior, and pagination (if any). This is adequate but not thorough.

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% (empty for mode and limit). The description adds meaning by explaining the 'mode' enum (lookup vs discover) and that 'query' can be a company name/domain or a discovery query. It also describes the 'filters' object content for discover mode. This compensates well for schema gaps.

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 'real-time intelligence on a startup/company by name or domain' and lists returns (profile, founders, tech stack, hiring signals, YC batch). It distinguishes between lookup and discover modes, and from sibling tools focused on contacts or scraping. However, 'intelligence' is slightly vague.

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 two modes (lookup for one company, discover for filtered list), providing some guidance on when to use each. But it offers no explicit exclusions or comparisons to sibling tools like hsh-b2b-contact, leaving the agent to infer the best tool.

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

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

No annotations provided, so description carries full burden. It discloses setup fee, per-record cost, and included services, but does not mention rate limits, auth, or potential side effects. Moderate disclosure.

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 reasonably concise, starting with core purpose then pricing. Minor redundancy (e.g., 'novel datasets that don't exist anywhere yet' is slightly verbose) but overall efficient.

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

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

Without output schema, annotations, or detailed parameter help, the description covers pricing and tiering but lacks details on output format, error handling, or prerequisites. Could be more complete for a custom dataset creation 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%. The description provides context for schema_description (plain English) but adds little for other params like sources_hint or delivery_format beyond the schema's empty 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 it provides novel datasets that don't exist yet, with specific examples like cross-domain fusion and industry-specific schemas. It distinguishes from sibling tools by emphasizing custom creation.

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 custom dataset needs with pricing tiers, but lacks explicit when-not-to-use or alternative tool guidance. Context signals show many sibling data tools, but no direct comparison.

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

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

With no annotations, the description carries the full burden. It discloses the process: receive price, scope, quote_ref, pay_url; pay via x402; delivery in 24h. It also mentions optional parameters (urgency, budget). It doesn't cover auth, rate limits, or failure scenarios, but for a quoting tool it provides effective 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 two sentences long. It is front-loaded with 'FREE.' Every sentence serves a purpose: stating what the tool does, what it returns, and how to proceed. 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?

With 3 parameters, no output schema, and no annotations, the description covers the tool's purpose, input parameters, and key outputs (price, scope, quote_ref, pay_url). It does not specify output structure, but the description lists the outputs clearly. For a simple quoting tool, it is largely complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context: 'need' is free-text, 'urgency' optional with no further detail (but enums are in schema), and 'budget_usd' is optional with the note 'we may accept it within our floor,' which adds 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 tool's purpose: 'Describe any data need in plain language and receive an instant firm quote.' It specifies the verb (describe), resource (HSH Intelligence Data-on-Demand), and outcome (price, scope, quote_ref, pay_url). It distinguishes from siblings like hsh_check_order and hsh_check_quote by noting it is for describing a need before purchasing custom data.

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

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

The description explicitly says 'FREE' and 'Use this BEFORE purchasing custom data,' providing clear context for when to use this tool. It implies alternatives by naming sibling tools (check_order, check_quote), but does not explicitly state when not to use it. The guidance is sufficient for an AI agent.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It only mentions 'FREE,' implying no cost, but does not describe rate limits, authentication needs, or whether the operation is read-only or destructive. The lack of detail leaves the agent uncertain about behavioral expectations.

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 that efficiently conveys the core purpose and a key advantage ('FREE'). It front-loads important information and contains no unnecessary words. Every part serves a purpose.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description is somewhat adequate. It explains what the tool lists and includes a call to action for custom orders. However, it does not describe the output format or any limitations, which could aid the agent. For such a simple tool, it is marginally 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?

The input schema has no parameters (empty object), and schema description coverage is 100%. According to guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter semantics since none exist; it appropriately omits extraneous 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 lists 'HSH Intelligence's catalogued data capabilities with live pricing, plus how to order custom data.' The verb 'list' is specific, and the resource is well-defined. This distinguishes it from sibling tools like hsh_check_order or hsh_describe_data_need, which have different functions.

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 is given on when to use this tool versus alternatives. The description implies it is for viewing capabilities and pricing, but it does not mention when to use other sibling tools like hsh_check_order or hsh_describe_data_need.

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 pricing, frequencies, and webhook alerts but omits behavioral traits like authentication needs, rate limits, 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 efficiently cover core purpose, features, and pricing without extraneous words. Each sentence adds value.

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

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

For a monitoring tool with multiple configurable parameters and pricing, the description covers high-level features but lacks detail on return format, error handling, or integration with other tools. Missing output schema exacerbates this.

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 40%, low. The description adds context for frequencies (daily, hourly, real-time) and pricing related to duration_months, but lacks explanations for webhook_url and alert_threshold beyond the enum. It does not fully compensate for the coverage gap.

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 performs 'Continuous URL/page monitoring with change detection', specifying key features like snapshots, webhook alerts, and screenshot archive. This distinguishes it from sibling 'hsh-web-scrape', which likely offers one-time scraping.

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 ongoing monitoring but does not explicitly state when to use this tool versus alternatives (e.g., for one-time scraping vs. persistent monitoring), nor does it provide exclusions 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?

With no annotations provided, the description must fully disclose behavioral traits. It mentions pricing and complexity multiplier but omits critical details like rate limits, authentication requirements, data freshness, error handling, or what happens when sites block scraping.

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 efficient, with purpose stated upfront. Pricing details add length but are relevant. Minor waste could be trimmed by separating pricing into annotations.

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?

Lacking output schema and annotations, the description should explain return format, pagination handling, and error states. It does not cover these, leaving the agent with insufficient information to use the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds pricing context but does not clarify parameter formats or expected values (e.g., how 'fields' are specified, meaning of 'all' for quantity).

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

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

The description clearly states the tool is for custom web scraping of structured data from public sites, specifying it handles static HTML, JS-rendered, paginated, and anti-bot scenarios. However, it does not explicitly differentiate itself from sibling tools like hsh-custom-dataset or hsh_describe_data_need.

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 pricing tiers but offers no guidance on when to use this tool versus alternatives (e.g., hsh-b2b-contact, hsh-company-intelligence). There is no mention of prerequisites, use cases, or exclusion criteria.

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