HSH Data-on-Demand

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

With no annotations, the description carries the burden and does disclose important behaviors: a real sample is built per call, counts of address types are returned, and certain fields are never offered. It does not mention that a call may open an order unless dry_run is set, nor that live=true reads company websites during the call, though these are partially implied by the schema.

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

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

The description is a dense paragraph but each sentence adds value, covering product definition, sample mechanics, pricing, and exclusions. It is longer than ideal but not wasteful, and the most important information is 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 the tool's complexity, no annotations, and no output schema, the description covers the key operational aspects: sample generation, quality counts, pricing model, and explicit non-offerings. It does not fully explain the order flow or how buyer_contact and dry_run interact, but the schema covers those 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds useful context about sources and validation but does not add per-parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource: named decision-makers at companies with the roles they actually hold, sourced from securities filings and accelerator cohorts. It is specific about what is delivered, though it does not explicitly contrast itself with 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?

The description implies usage by describing the data product, sample behavior, and exclusions such as no personal phone numbers and no bounce-rate guarantee. However, it does not explicitly state when to prefer this tool over the sibling B2B tools or provide alternative routing.

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 behavioral burden and does disclose non-obvious traits: a real sample is returned on every call, pricing is on request, and no source provides a per-person LinkedIn URL. It also notes the data comes from the same two sources plus the filed entity record. It does not cover order placement or return format, but the disclosures go beyond the schema.

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

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

Two sentences front-load the core value proposition and then add commercial behavior and a key limitation. Every clause earns its place; there is no redundant filler.

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

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

For a 10-parameter tool with no output schema and no annotations, the description gives a solid high-level picture but leaves gaps: the 'two sources' are unnamed, the relationship to hsh-b2b-full is unaddressed, and order/quote mechanics are only hinted at. The schema fills parameter specifics, so the description is adequate but not fully complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description does not add parameter-level detail. It lists output fields rather than explaining input parameters, which is acceptable given the schema's thoroughness.

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 the named-contacts product plus company-level attributes, enumerating specific fields such as industry, location, headcount, stage, ticker, exchange, state of incorporation, and entity type. It differentiates from the basic contact product, though it lacks an explicit action verb and refers to the sibling only as 'named-contacts product'.

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 'plus the company around the person' phrasing implies this is the choice when company context is needed, and the 'No LinkedIn URL' note sets an expectation boundary. However, it never explicitly names alternatives like hsh-b2b-contact or hsh-b2b-full, nor states when not to use this 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, the description carries the full burden and does disclose key constraints: it excludes personal phone numbers and revenue estimates, and states that a real sample is returned on every call with pricing on request. It also hints at order behavior through the dry_run parameter ('without opening an order'). However, it does not explicitly warn that a normal call will open an order or describe any side effects beyond that, so it is only moderately transparent.

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

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

The description is a single dense, run-on paragraph with no headers or bullet points. It front-loads 'Every field a record carries' but then rambles through a long list and exclusions without breaking them down. The critical information about exclusions is buried in the middle, and the pricing/order concept appears only at the end. This is verbose and poorly structured for an AI agent that needs to parse it quickly.

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 covers the essential operational context: that a real sample is returned immediately, that the batch is quoted, and that dry_run returns sample+quote without opening an order. It also clarifies the scope of data (filings vs. cohort). However, with 10 params and no output schema, it does not describe the response format beyond 'real sample' and 'quote' – it never explains what the sample structure looks like or how the record fields map to the schema. For a tool with this complexity, it is adequate but not 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 schema has 100% coverage with descriptions for all 10 parameters, so the baseline is 3. The tool description adds context about the overall data fields but does not clarify individual parameter semantics beyond what the schema already provides. For example, 'live' and 'live_budget' are not expanded in the description, even though they may interact in ways not obvious from the schema alone. It does not degrade, but it does not improve either.

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 enumerates the data fields and exclusions but never states the action the tool performs (e.g., 'fetches', 'provides', 'quotes'). It reads more like a data sheet than a tool definition, leaving the agent to infer the operation from the name and schema. It does distinguish itself as 'full' coverage, but without a clear verb+resource it is only vaguely purposeful.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of sibling tools like hsh-b2b-enriched or hsh-b2b-contact. The phrase 'withheld from no tier' hints at a comparison, but it never tells the agent when to prefer this over alternatives. The description implies it is the comprehensive option but leaves the decision entirely to inference.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does this thoroughly: it discloses the data source freshness (copy dated 14 Apr 2026), potential inaccuracies (names may be partners/investors), that every response includes source_path, that live-hunt-only responses list what they couldn't provide, and that payment is via x402 (USDC on Base). This goes well beyond what the schema reveals and gives the agent a realistic expectation of 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 a single, dense paragraph that front-loads the core purpose and then efficiently lists key behaviors, data limitations, and payment. Every sentence adds value: output fields, YC specifics, source freshness, source_path, discover mode, and payment. No fluff or repetition.

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 4 parameters and no output schema, the description covers most essential operational aspects: what it returns, modes, source freshness, what it cannot provide, and payment. It does not explain how limit affects results or default values for mode, but these are minor gaps given the richness of behavioral disclosure. Overall, an agent has sufficient context to call 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?

The schema has 50% description coverage: query and filters have descriptions, while mode and limit are empty. The tool description adds some clarity for mode (explains discover as a filtered list of YC companies) and indirectly for filters (by stating no contact-detail filter exists). However, it does not explain the limit parameter or provide format examples for query or filters. It adds marginal value but does not fully compensate for the missing 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's function: providing real-time intelligence on a company by name or domain. It enumerates the always-returned fields (profile, description, industry, tech stack, social links) and distinguishes two modes (lookup and discover). This is specific and distinct from sibling tools like hsh-b2b-contact, which focus on contacts, and cricket tools, making the purpose unambiguous.

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

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

The description provides clear context for when to use the tool: for company intelligence by name/domain, and it explains the discover mode as a filtered list of YC companies. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusions and alternative guidance. It gives enough context to select it appropriately 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 transparently states it provides a historical rate from a specific dataset (4,502 chases through 17 Sep 2026) and mentions optional ground record. It doesn't disclose potential rate limits or exact output format, but it gives sufficient context for a read-only query.

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, tightly packed sentence that front-loads the core purpose and then adds precise details (range, interval, sample size, date, optional ground record). Every clause adds value.

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

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

For a simple 2-parameter tool with no output schema, the description provides the essential context: the statistic, the data scope, and the optional parameter. It doesn't describe the return format, but that's not critical for a historical-rate query.

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 both parameters with 100% coverage. The description adds context: 'target' is interpreted as a target within 10 runs of yours, and 'venue' is for an optional ground-specific record, enriching the schema definitions.

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: it returns the historical chase-down rate for similar targets in men's T20, with specifics like range, sample size, and interval. This distinguishes it from sibling tools like winprob which likely give probabilities, by focusing on historical frequency.

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 historical chase difficulty but does not explicitly state when to use it over alternatives like hsh-cricket-chase-winprob. It gives context (men's T20, within 10 runs) but lacks explicit when-to-use/when-not-to-use guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: evaluation AUC, training-data cutoff, the small effect of naming the ground, and a per-call cost note. However, it does not state the output format or explicitly confirm that this is a stateless read-only prediction, though 'from the match state you send' implies it.

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 short and front-loaded with the core purpose, followed by a concise performance statement and cost note. Every sentence contributes, though the performance data could be seen as secondary rather than essential.

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 prediction tool, the description conveys enough context: the model type, input state, validation performance, and venue handling. The absence of an output schema means the exact response shape is not guaranteed, but 'win probability' plus the venue parameter's note that 'the answer says which ground was used' gives reasonable expectations.

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%, and the schema already explains each parameter including target, wickets, and the balls_bowled over-count convention. The description adds no new parameter-level meaning beyond reinforcing that the match state is the input, so the baseline 3 applies.

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

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

The description names a specific verb and resource: computing win probability for the side chasing in a men's T20 from a given match state. This is immediately distinguishable from siblings like hsh-cricket-first-winprob and hsh-cricket-chase-difficulty.

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 phrase 'for the side chasing in a men's T20' provides clear context for when the tool applies, and the optional ground parameter signals when venue data matters. It does not explicitly name alternatives or exclusions, but the intended use case is unambiguous.

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 present, the description carries the burden of behavioral disclosure and does a reasonable job: it states that rankings come 'from each player's own record before the match' and provides measured accuracy figures on 236 matches. This gives useful expectations about data recency and performance, though it does not describe error behavior or output shape.

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 the performance statistics are contained in a single sentence. The trailing 'Per call.' adds little for tool invocation and stops the score from reaching 5, but overall the description is well-structured and not bloated.

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 and schema together cover the input requirements well, but there is no output schema and the description does not explain the exact return shape beyond the inferred ranking and captain/vice-captain selections. The schema's mention of `not_recognised` hints at output behavior, but the overall response format is not fully specified.

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

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

Schema description coverage is 100%, so the schema already explains each parameter, including the deprecated venue and is_chase fields. The main description adds no parameter-level detail beyond reinforcing that the tool ranks the submitted players, so the baseline 3 is appropriate.

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

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

The description clearly states the tool ranks an agent-supplied set of players for a men's T20 fantasy team and selects a captain and vice-captain. It is unambiguous about the resource and action, though it does not explicitly differentiate itself from the cricket sibling tools such as hsh-cricket-form or hsh-cricket-matchup.

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 when to use the tool (when you have players to rank for a T20 fantasy team), but it gives no explicit guidance about when not to use it or what alternative sibling tools should be used instead. There is no mention of exclusions such as women's matches, live matches, or non-T20 formats.

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 transparency burden. It discloses the model's validation performance (AUC 0.912 with team names and ground, 0.888 with ground only) and the evaluation window, which helps an agent understand reliability. It does not describe the output format, but 'win probability' already implies the basic result.

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 compact and front-loaded with the core purpose in the first sentence. The validation statistics are useful but somewhat detailed; 'Per call' is terse and slightly ambiguous, yet the overall structure is 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?

The description gives enough context for tool selection and mentions model performance, but it does not state the exact return shape (e.g., a probability between 0 and 1) or explicitly clarify that optional team names improve accuracy. It still feels minimally viable given the comprehensive schema.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds minimal extra semantic value beyond confirming that team names and ground are relevant features, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as returning win probability for the side batting first in a men's T20 while the total is being set. It distinguishes this from the sibling chase-winprob tool by specifying the first-innings context, though it lacks an explicit verb like 'calculates'.

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 phrase 'while the total is being set' implies this is for the first innings, and the sibling list includes chase-winprob for the opposite scenario. However, the description never explicitly says when to use this tool instead of alternatives or 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 the measurement window (through 17 Sep 2026), the player population (2,739 established players), and the empirical calibration (red-hot players scored 11% above average; out-of-form 5% below). It also notes 'Per call' and that partial name matches are resolved with the answer naming who was used and who else matched. This is strong behavioral context beyond a simple 'get form' statement.

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 dense but efficient: it packs the metric, scope, date, and calibration into two sentences. The key information is front-loaded (what the tool measures) and the calibration detail is a useful addition. It could be slightly tighter, but every sentence earns its place.

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

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

For a single-parameter tool with no output schema, the description is quite complete. It explains the input matching behavior, the population, the date cutoff, and the meaning of the form labels. The only minor gap is that it doesn't describe the exact output structure (e.g., whether it returns a numeric form score or just a label), but the calibration sentence partially covers 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that the player parameter accepts partial names and that the answer will disambiguate ('the answer names who was used and who else matched'). This goes beyond the schema's example and clarifies matching behavior, which is valuable for correct invocation.

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 a specific verb and resource: it measures a men's T20 player's current form against their own career average, plus bowling workload and last five appearances. It clearly distinguishes itself from sibling tools like hsh-cricket-matchup or hsh-cricket-momentum by naming the exact metric (red-hot to out-of-form) and the player scope (2,739 established players through 17 Sep 2026).

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 when to use this tool: when you need a player's form relative to their own average, bowling workload, and recent appearances. It doesn't explicitly name alternatives or exclusions, but the specificity of the metric and the mention of 'Per call' provide clear context. A small gap: it doesn't say when NOT to use it (e.g., for team-level analysis or other cricket 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 behavioral burden. It adds useful context about dataset size, match count, competitions, cutoff date, and per-call granularity, and implicitly indicates a read-only query. It does not mention response format, authentication, rate limits, or any side effects, though the tool's read-only nature can be inferred.

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 dense sentences with every clause earning its place: the core function comes first, and the dataset-scale and date-cutoff details provide useful context without padding.

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 two-parameter lookup with no output schema, the description covers purpose, scope, output statistics, dataset size, and freshness. The only minor gap is that it does not spell out the exact response structure, but the listed fields largely compensate.

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 both parameters fully with descriptions and examples, so the baseline is 3. The main description adds no additional parameter-level meaning beyond identifying batter and bowler as the two roles.

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 names the resource—a batter's record against a bowler in men's T20—and enumerates the exact statistics returned. It lacks an explicit action verb like 'Retrieves' and does not explicitly contrast with sibling tools, but the data product is specific enough that an agent can tell it apart from the other cricket tools.

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

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

The scope (men's T20, specific leagues, cutoff date) implies when this tool is relevant, and there is no apparent overlap with sibling cricket tools. However, it never states when to prefer this over an alternative or provides any explicit when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full disclosure burden. It only adds 'Pay per call via x402,' and does not mention whether the call is read-only, what the returned index looks like, how to interpret the swing signal, or failure modes beyond what appears in the schema's parameter notes.

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 short sentences with the core output first, then use context, then billing. There is no filler, and every sentence contributes to selection or invocation.

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 no-output-schema tool with no annotations, the description leaves the output format and index interpretation unspecified. However, the parameter schema is unusually thorough, so the agent has enough information to construct a valid request even if it cannot predict the exact response.

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

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

Schema description coverage is 100% and the parameter descriptions already detail prev, curr, target, and venue including edge cases like ball count and wrong-order refusal. The main description adds no parameter-specific meaning, so the baseline 3 applies.

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

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

The description clearly identifies the resource as a 'Momentum & pressure index for a live T20 chase' and says it 'quantifies which side is gaining' along with a pressure score. This separates it from sibling tools like winprob or chase-difficulty by output type, though it stops short of naming any sibling explicitly.

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?

It gives clear context: it is for a live T20 chase and is an in-play trader signal, which tells an agent when this tool is relevant. It does not mention alternatives or exclusion conditions, so it lacks the explicit routing of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses model performance (median error, band coverage), training-data cutoff, and per-call framing. It does not mention side effects, but this is a read-only prediction tool and no such disclosure is necessary.

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

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

The description is two sentences with no filler: the purpose is front-loaded, and the performance statistics are compact and relevant. 'Per call' is terse but meaningful.

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 prediction tool with a fully described schema, the description provides enough context: what it returns, its accuracy, and its data scope. It does not detail the exact response structure, but no output schema exists and the high-level description is sufficient for 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 100%, so the schema already documents all four parameters. The description adds little beyond the high-level 'from the score you send,' which is acceptable given the schema's completeness.

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 a specific action ('Projected first-innings total') and resource ('men's T20') with a clear scope. It distinguishes itself from sibling cricket tools by focusing on first-innings par score rather than 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?

The description implies when to use it: when you have a current T20 score and want a projected first-innings total. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the boundary against sibling cricket 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 are provided, so the description carries the burden. It discloses the core behavior: one output point per input state, in the order sent, limited to men's T20 chases and computed by the same model as the sibling tool. It does not describe exact response format or error behavior, but 'one point per match state' is a substantive behavioral disclosure for a stateless computation.

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?

One dense sentence with the core object front-loaded ('Win-probability timeline'), scope defined, model provenance included, and a terse 'Per call.' closer. Every phrase earns its place and there is no filler.

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

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

For a simple 3-param tool with no output schema and no annotations, the description is nearly complete: it states the output shape ('one point per state'), ordering, scope, and model provenance. It only leaves the exact response format and the explicit single-state alternative slightly implicit, which is a minor gap.

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

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

Schema coverage is 100% and the schema already documents every parameter richly, including events structure, legal-balls formula (12.3 overs = 75), target meaning, and venue application. The description does not add parameter-specific meaning beyond the schema, so the baseline 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 states a specific verb and resource: 'Win-probability timeline (the broadcast worm) for a men's T20 chase' with 'one point per match state you send.' It also names the sibling model it derives from (hsh-cricket-chase-winprob), helping an agent distinguish it from related cricket tools.

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

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

The description gives clear context: this is the timeline variant, producing one point per match state sent, and it explicitly ties itself to hsh-cricket-chase-winprob as the source model. It does not explicitly state 'use chase-winprob for a single state' or list exclusions, but the per-call/per-state phrasing makes the intended use apparent.

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 and does well: it discloses that it is 'Descriptive, not a forecast,' notes it is 'per call' (stateless), and mentions the extra BTC transaction data. It does not cover rate limits or error conditions, but for a read-only data query these are less critical; the description provides enough 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?

The description is dense but well-organized, front-loading the core purpose and then listing metrics in a logical sequence. It avoids redundancy, though it is longer than average; every sentence contributes either a metric, a limitation, or an asset-specific detail, making it appropriately sized for the tool's 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?

For a complex tool with no output schema, the description covers the key outputs: funding from two venues, open interest, the positioning signal categories, stress measurement in standard deviations, and the BTC-specific block data. It does not explain computation details or response format, but the essentials for an agent to understand what it will receive are present.

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 schema coverage is 100%, the description adds value beyond the schema by listing the supported assets (BTC, ETH, SOL, BNB, XRP, DOGE) and clarifying that BTC receives additional block-transaction data. It also reinforces the default asset (BTC) and the optionality of the symbol, giving the agent a fuller understanding of parameter behavior.

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 a specific verb ('Crypto positioning for trading agents') and a precise resource (funding, open interest, positioning signal, stress, and BTC transactions) for a defined asset list. It clearly distinguishes itself from all sibling tools, none of which are crypto-related, and avoids tautology by detailing what data is delivered.

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 gives clear context for when it would be used (trading agents needing crypto positioning) and what it covers, but does not explicitly contrast with alternatives or state when not to use it. Given that no sibling tool overlaps in purpose, the lack of explicit exclusions is acceptable, though a direct 'use this for crypto positioning' would be stronger.

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 burden and does well: it discloses the tool is free, that the quote is firm and frozen, the payment rail (x402, USDC on Base or Solana), and the 24h delivery window. It omits whether a quote expires, auth requirements, or rate 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?

Front-loads the key qualifier 'FREE' and then the outcome, payment path, and ordering advice in a tight sequence. Slightly dense with workflow and sibling-routing detail but every sentence carries information an agent needs.

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

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

There is no output schema, yet the description enumerates the returned fields (price, scope, quote_ref, pay_url) and the downstream step (pay via x402 to place the order). Combined with the email-contact caveat, an agent has enough to invoke and act on the result, though quote validity windows remain unspecified.

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 all five parameters are already documented in the schema. The description echoes the contact_email necessity but adds no extra syntax or format guidance beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb (describe) and resource (data need) and enumerates what comes back: price in USDC, scope, frozen quote_ref, pay_url. It also distinguishes itself from siblings hsh-custom-dataset and hsh-finetune-dataset by stating those are quoted here rather than called directly.

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?

Gives explicit sequencing advice: 'Use this BEFORE purchasing custom data,' and clarifies that custom-dataset and finetune-dataset orders route through this tool. It does not, however, say when to prefer one of the other data siblings like hsh_broker_data_request over this one.

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 behavioral burden and discloses the fixed universe, SEC EDGAR source, classification logic, severity grading, and payment mechanism. It omits rate limits and error/failure behavior, but for an intel lookup tool this is substantial 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?

The description is long but every sentence carries relevant information: purpose, universe, source, classification, filters, and payment. It front-loads the primary purpose and then details operational context, though a few clauses could be tightened.

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 complex and has no output schema, so the description should explain return structure. It covers data provenance and classification but not the actual response shape, pagination, or error cases. Adequate for a basic call but not fully 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%, but the description adds meaningful semantics beyond the schema: it explains that ticker can scan outside the default watchlist and that pillar filters by E, S, or G. This goes beyond the schema's generic 'Filter to one company'.

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 identifies the resource as company-attributed ESG material-event intel from SEC filings and enumerates event types. It distinguishes itself from sibling tools like hsh-esg-news by specifying 8-K/SD sources and event-to-pillar mapping.

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 clear context on when to use it: to scan the fixed 35-name watchlist or pass a ticker to reach outside it. It does not explicitly name alternative tools or give when-not-to-use rules, but the context is strong enough to guide selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions real-time detection, enrichment with GLEIF and sanctions screening, pillar classification, severity grading, source linkage, and a specific data-quality constraint (company must be named in the web address). It also discloses payment via x402 (USDC on Base). This is substantial, though it does not specify return format, pagination, or rate 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?

The description is moderately sized but packed with relevant information. It front-loads the purpose and then details features, constraints, and payment. While not as terse as the high example, it remains efficient and free of fluff, with each sentence contributing to usability.

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 read-only retrieval tool with no required parameters and no output schema, the description provides a good deal of context: it explains what is returned (pillar-classified, severity-graded, source-linked controversies with enrichment) and the key constraint. It does not detail exact fields or handling of limits, but given the complexity and optional parameters, it is reasonably complete.

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

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

The input schema already documents all four parameters with 100% coverage. The description adds some value by providing a concrete example for the region parameter and explaining the company-name condition, but these are minor augmentations. Since the schema does the heavy lifting, the baseline of 3 is appropriate.

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

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

The description clearly states the tool detects ESG controversies from worldwide news in real time, enriches with GLEIF entity resolution and EU sanctions screening, and classifies by pillar, severity, and source. It explicitly distinguishes from the sibling tool hsh-esg-events (SEC-filing product), making its purpose and uniqueness immediately clear.

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 this tool (news-derived breadth) versus the authoritative SEC-filing product hsh-esg-events. It also gives a specific usage instruction for the region parameter ('Pass region='EU' for companies domiciled in the 27 EU member states'). However, it does not explicitly state conditions for when NOT to use it, but the complementary nature is implied.

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 transparency burden. It discloses that the tool aggregates six signals, states the pay-per-call cost via x402, and explicitly disclaims price prediction. It does not mention rate limits or error handling, but the disclosed behaviors are material for an agent deciding whether to call the tool.

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

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

The description is long but information-dense, front-loading the purpose and then enumerating the six signals in a numbered list. Every clause either defines a signal, scopes the output, or states payment terms; there is no filler. It is appropriately structured for an agent to parse.

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 9 parameters and no output schema, the description must compensate for missing return-type information. It explains input identifiers and gives a high-level 'operational and behavioural readings' summary, but does not describe the output structure, scale, or how the six signals combine into a final result. An agent can invoke correctly but may be uncertain about the expected response.

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

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

Although the input schema already gives 100% param coverage with examples, the description adds semantic grouping: greenhouse/lever/ashby map to hiring posture, ticker to insider activity, github to engineering velocity, wiki/hn/ios_app to the remaining signals. This helps an agent understand how to combine parameters meaningfully, adding 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 a specific verb and resource: it combines six independent free signals into one call, listing all six sources (hiring posture, insider activity, GitHub, Wikipedia, App Store, Hacker News). This distinguishes it from sibling tools like hsh-company-intelligence or hsh-crypto-intel, which focus on different data types.

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 ('alt-data intel for investment research') and a negative boundary ('no price prediction is made or claimed'), which implies appropriate use cases. However, it does not explicitly compare itself to sibling alternatives nor state when an agent should prefer this tool over a single-signal tool, leaving selection partially to inference.

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 behavioral burden and does substantial work: it discloses the unfiltered market-wide fallback, the enrichment fields per announcement, whether provenance came from a language model or fixed rules, and the pre-payment refusal for empty symbols. It does not describe refresh or pagination behavior, but those are secondary.

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

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

Four dense sentences, each earning its place: scope first, modifier behavior second, record enrichment third, edge case and payment guard last. The category list is long but useful for setting caller expectations, and there is no filler.

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

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

Without an output schema, the description compensates by explaining what each item contains: filing category, sentiment, one-line summary, and provenance. It also covers the main behavioral branches and a payment-related edge case. It omits details like default limit and exact response shape, but the essential calling context is present.

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, and the description adds real value: concrete symbol examples (RELIANCE, TCS), the behavior when symbol is omitted, and the refusal case for symbols with no announcements. The limit parameter is left mostly to the schema's own description.

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

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

The description clearly identifies the resource: corporate announcements filed with the NSE by Indian listed companies, ordered newest first. The symbol/no-symbol distinction makes the tool's scope precise and distinguishes it from siblings like hsh-india-fundamentals and 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?

It gives explicit usage context: providing a symbol returns that company's own record, while omitting one returns the exchange's latest market-wide page. It does not explicitly name alternative tools or state when not to use this one, so it stops short of full when/when-not guidance.

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

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses the data source ('from each company's own filed results'), consolidation behavior ('Consolidated where the company files it'), freshness mechanism ('Every block carries its own date and age'), and units ('Values in INR crore'). It does not discuss auth, rate limits, or error behavior, but for a read-oriented data tool this is strong 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 dense and information-rich, but it is structured as one long run-on paragraph. Every element is relevant, yet breaking the content into bullets or shorter sentences would improve scannability. It is not overly verbose, but it is not optimally structured.

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

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

The description is unusually complete for a tool with no output schema: it enumerates the exact metrics, periods, ratios, shareholding fields, units, and input requirement. The main gap is that the 'period' parameter is optional but no default behavior is stated, and the response shape is not described. Overall, an agent has enough context to call this 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 both parameters are already documented. The description adds only 'Pass an NSE trading symbol,' which largely repeats the schema. Baseline 3 is appropriate because the schema handles parameter semantics adequately.

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 resource: Indian listed-company fundamentals sourced from filed results, including P&L, balance sheet, ratios, and shareholding pattern. It is specific and unambiguous, though it does not explicitly differentiate this tool from potentially overlapping siblings like 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 states the key invocation requirement: 'Pass an NSE trading symbol. Per call.' This gives clear how-to context but no explicit when-to-use guidance, alternatives, or exclusions relative to sibling tools. Usage is implied rather than fully specified.

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 the detailed scope of returned data: dated oil futures with 30-day change, macro indicators with years, currency regime, live equity price and 52-week position, and TASI level/breadth/mood. It also states what is not included. It does not mention side effects, rate limits, or response format, but as a read-only intelligence tool the main behavioral traits are 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 packs a lot of useful information but is a single dense run-on sentence with nested parentheticals. It is front-loaded with the domain, but the structure makes it harder to parse than necessary. Every clause earns its place, but the formatting could be clearer.

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

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

There is no output schema, so the description must explain what the agent receives. It does so in detail: oil futures with dates and 30-day change, macro with years, currency regime, equity price and 52-week position, and TASI level/breadth/mood with per-stock quotes. It also states the key exclusion. It lacks explicit response formatting or error behavior, but it is sufficient for invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds that a country code should be passed and a ticker is optional, and it ties the ticker to live equity pricing. However, it does not elaborate on country code values beyond the schema, and it implies country is required while the schema marks it optional, a minor inconsistency.

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 Gulf/MENA market intelligence and enumerates its contents: oil futures, macro data, currency regime, equity pricing, and TASI. This distinguishes it from sibling tools focused on other domains. It lacks a crisp imperative verb like 'retrieve' or 'list', but the resource and scope are unambiguous.

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

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

The description gives clear context: it is for trading agents needing Gulf market data, and it explicitly states an exclusion ('Market-level: no company financial statements'), which helps rule out company-level alternatives. It does not name sibling tools or provide explicit when-to-use/when-not-to-use comparisons, but the context is strong.

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

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

With no annotations, the description carries the full disclosure burden and does so substantively: baseline-on-subscription, check frequencies, visible-text change measurement, recording of every check, webhook behavior, and per-URL pricing. It omits payment/refund/cancellation mechanics, but those are less central to invoking the tool correctly.

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

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

Four concise sentences, each carrying a distinct fact: purpose/frequency, change-detection behavior, recording/webhook, and pricing. Front-loaded and free of filler.

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

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

Strong on purpose and behavior, but since there is no output schema and no annotations, the description does not say what the call returns (e.g., subscription ID or confirmation), the default duration when duration_months is omitted, or how the urls list should be delimited. For a paid subscription-style tool, these are meaningful gaps.

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 60%, and the description compensates by explaining re-check intervals, webhook behavior, and $10/URL/month pricing. It still does not clarify the expected string format for urls or the default if duration_months is omitted, but it adds meaning beyond the bare 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?

States a specific action and resource: 'Continuous monitoring of public web pages with change detection.' The phrase 'continuous monitoring' clearly distinguishes this from one-off fetching/scraping, especially relative to the sibling hsh-web-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?

Clearly conveys the intended use case: pages are baselined on subscription and re-checked hourly, daily, or weekly. It does not explicitly name alternatives or say when not to use the tool, but the continuous-monitoring context is unambiguous.

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 the methodology (total assets bases, thresholds), notes that boards using market cap may differ, and states the 5% revenue test is not assessed. This is thorough, though it could mention that the screen is based on filed financial statements and may be stale.

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 dense but organized with numbered lists, front-loading the core purpose and then detailing the screen components. It is long, but every sentence adds necessary methodology details. Could be slightly tightened, but clear structure earns a high score.

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

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

For a single-parameter tool with no output schema, the description covers the input, the methodology, limitations, and return values (verdict with ratios). It misses explicit mention of date of financial statements or potential delays, but overall it is sufficient for an agent to know what to expect.

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

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

The schema already describes the `ticker` parameter with examples (AAPL, XOM, JPM) and states it is a US-listed ticker. The description reiterates it is for US-listed companies, but adds no new semantics beyond that. Since coverage is 100%, a baseline of 3-4 is justified; slight extra clarity on the scope (US-listed) earns a 4.

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

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

The description clearly identifies the tool as a rule-based Shariah screen for US-listed companies, specifies the input (ticker), and outlines the business-activity and ratio screens. It distinguishes itself from sibling tools by its domain focus and methodology.

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 when to use this tool (when a Shariah compliance screen is needed) but does not explicitly contrast it with alternatives or state when not to use it. However, the context is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses that the tool reads server-delivered HTML only, refuses JS-rendered and authenticated pages, follows pagination, deduplicates, and reports field presence frequency. It also states the pricing model. These are non-obvious behaviors beyond the schema, making the description transparent.

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

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

The description is three sentences, front-loaded with the core action, then enumerates behaviors, then states the HTML limitation and pricing. Every sentence adds information; there is no filler or repetition. The structure is efficient and scannable.

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

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

For a complex tool (pagination, dedupe, refusal conditions, reporting), the description covers the essential operational aspects: what it does, what it refuses, pricing, and output behavior (field presence report). It does not specify the exact output schema, but that is not required in the absence of an output schema. It also does not mention rate limits or error handling, but these are minor gaps given the clarity of the rest.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by clarifying that 'fields' are extracted per record and that the tool reports how often each field was present, giving semantic meaning to the fields parameter. It also ties 'quantity' to the per-record pricing model, which supplements the schema's numeric constraints.

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 opens with a specific verb-resource pair ('Extract structured records from a public web page') and enumerates concrete behaviors (finds repeating block, pulls named fields, follows pagination, removes duplicates, reports field presence). It clearly distinguishes itself from the data-intelligence siblings (hsh-b2b-contact, hsh-company-intelligence) by focusing on raw HTML scraping and explicitly scoping to public pages.

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 gives explicit conditions of use: it works on static public HTML and explicitly refuses dynamic (JS-rendered) or login-protected pages before charging. It also states pricing per record, which helps an agent decide based on cost. It does not name alternative tools, but the refusal conditions and 'public web page' scoping are strong usage guidance.

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