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

No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses the response shape ('every matching scope entry plus the program's exclusions as caveats'), which tells the agent exclusions arrive as caveats rather than verdicts. However, it says nothing about auth requirements, rate limits, or how a non-matching asset is represented.

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 compact sentences with the decision purpose front-loaded and the return behavior second. No filler 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?

An output schema exists, so explaining return values is a bonus rather than a necessity, and the description still notes the caveats structure. The main gap is the undocumented 'handle' parameter, which the description does not resolve.

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

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

Schema description coverage is 0% for both parameters. The description compensates partially by defining the accepted 'asset' forms (host, URL, IP, CIDR), but the 'handle' parameter is left entirely unexplained in both schema and description, so the agent must guess what identifies the program.

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+resource ('Decide whether an asset ... is covered by a program's structured scope') and enumerates the accepted asset forms (host, URL, IP, CIDR). This distinguishes it from siblings like get_structured_scopes or get_scope_exclusions, which list rather than evaluate a specific asset.

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 purpose implies the usage scenario (evaluating one asset against a program's scope), but there is no explicit when-to-use or when-not-to-use guidance relative to siblings such as get_structured_scopes or get_scope_exclusions. The agent must infer that this is the per-asset membership check.

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 behavioral burden. It does disclose a real trait — that program metadata is truncated — and explains the flag-driven consolidation behavior. But it says nothing about permissions, whether the caller must be a program member, rate limits, or what the truncation means for completeness, leaving notable gaps for a tool with zero annotation coverage.

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 compact sentences with no filler, and the resource statement is front-loaded before the flag guidance. The cryptic "(truncated)" marker is the only element that costs clarity without adding meaning.

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?

An output schema exists, so return values need not be explained, and the flag consolidation guidance is a useful addition. Still, with no annotations, an unexplained required handle parameter at 0% schema coverage, and an ambiguous truncation note, the description is only adequate rather than complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify with_scopes and with_exclusions (include structured scope and/or scope exclusions) and that they can be combined in one call, which is genuinely more than the bare titles offer. The required handle parameter — the sole identifier and the key to the whole call — is left entirely unexplained in both schema and 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 identifies the resource (program metadata and policy) but uses no verb and never states that it returns data for the single program named by the handle parameter. The parenthetical "(truncated)" is ambiguous — it could mean the tool's output is truncated or that the description itself was cut off, which muddies the stated purpose. It only weakly differentiates from siblings get_structured_scopes and get_scope_exclusions by noting that their data can be pulled "in one call."

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

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

The second sentence implies a usage pattern: set with_scopes/with_exclusions to fold the sibling tools' data into a single call, which is a soft alternative to calling get_structured_scopes or get_scope_exclusions separately. However, it never says when to use this tool versus those siblings, and there are no exclusions or prerequisites (e.g., authentication, program membership).

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 behavioral burden. It implies a read-only lookup but says nothing about permissions, whether results are program-specific, rate limits, or freshness. With an output schema present, return-shape disclosure is not required, but the remaining behavioral context is thin.

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?

A single front-loaded sentence with no filler. The parenthetical clarifying 'out-of-scope classes' is the only elaboration, and it earns its place; nothing is wasted, though there is very little content overall.

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 one parameter and a present output schema, the definition is nearly sufficient: it says what is returned. However, it omits what 'handle' identifies and how this list differs from the scope data returned by get_structured_scopes, leaving a genuine routing gap for an agent.

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

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

Schema coverage is 0% and the sole parameter 'handle' is never mentioned in the description. The agent must infer that handle means a program handle and how it relates to the exclusions returned. The description does not compensate for the schema 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 states a specific resource and scope: categories excluded from rewards (out-of-scope classes). The verb 'Report' is slightly odd for a getter, and it does not explicitly distinguish itself from nearby siblings like get_structured_scopes or check_in_scope, but the purpose is clear and 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?

There is no when-to-use guidance, no prerequisites, and no named alternative. An agent reading this cannot tell whether to call it instead of get_structured_scopes or check_in_scope, which is exactly the confusion this tool needs to resolve.

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 behavioral burden. It discloses the return fields (identifier, type, bounty eligibility, max severity), which is mild content transparency, but says nothing about permissions, auth, pagination, or whether the list is complete.

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?

Very short and front-loaded with the core resource, so it is not verbose. But it is a sentence fragment rather than a structured statement, and the terse field list substitutes for real explanation.

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?

An output schema exists so return values need not be explained, yet the description omits the required handle argument, prerequisites, and any routing guidance. For a program-scoped read tool with no annotations, this leaves too much to inference.

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

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

There is one required parameter (handle) with 0% schema description coverage, and the description never mentions it. The agent must guess that 'handle' is the program identifier referenced by 'a program' in the 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 identifies the resource (in-scope assets for a program) and the fields returned, so an agent can infer it retrieves scopes. However it is a noun phrase with no verb, and it never distinguishes itself from siblings like check_in_scope or get_scope_exclusions, which sound equally scope-related.

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 guidance on when to call this versus check_in_scope, get_scope_exclusions, or get_program. The word 'program' implies a program handle is needed, but no prerequisite or context is stated.

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, yet it discloses nothing about auth/permission requirements, rate limits, pagination behavior, or result scope. The only behavioral hint is that sort defaults to newest, which is arguably parameter semantics rather than 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?

Two compact sentences with no filler, and the core purpose is front-loaded ahead of the syntax detail. Efficient and well-ordered, though the syntax example could arguably be trimmed.

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?

An output schema exists so return values need not be explained, which the description correctly omits. But for a 4-parameter, zero-coverage, unannotated tool it leaves page/limit semantics and sibling differentiation uncovered, making it only minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does add real value for `query` (HackerOne Lucene syntax with a concrete example) and `sort` (default and example '-disclosed_at'). However, `page` and `limit` are left completely undocumented, so half the parameters remain opaque.

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 ('Search') and resource ('disclosed reports'), and the parenthetical '(dedup / prior art)' clarifies the intent. It does not, however, differentiate from the near-identical sibling search_disclosed_reports, leaving the agent to guess which one to pick.

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 '(dedup / prior art)' note implies the use case for this tool, but there is no explicit when-to-use, when-not, or mention of the overlapping sibling search_disclosed_reports. Usage must be inferred rather than read.

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 disclosure burden. 'List' and 'programs you can access' imply a permission-scoped read, but the description says nothing about pagination behavior, rate limits, or the result shape beyond handles. Adequate but thin for a tool with zero annotation coverage.

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 tight sentences, front-loaded with the core action, then filters, then the return-value purpose. No redundant or wasted phrasing.

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?

An output schema exists, so return values need not be re-explained, and the description correctly points to handles as the takeaway. The remaining gap is undocumented pagination parameters and the absence of any behavioral notes for a tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so only partially: it explains query (handle/name substring), offers_bounties (bounty eligibility) and submission_state, but says nothing about the page and limit pagination parameters the schema exposes.

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 and resource ('List HackerOne programs') and adds scope ('you can access'), which lets an agent distinguish it from the singular get_program sibling. It does not explicitly name or contrast with siblings, but the list-vs-get distinction is implicit.

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 clear context: filter by bounty eligibility, submission state, or a handle/name substring, and the closing line 'Returns handles to feed the other tools' signals the downstream workflow. No explicit when-not or alternative-tool routing, so it stops short 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only discloses that results are scoped to the caller's own reports. It says nothing about auth requirements, whether the list is paginated or bounded, or how state/severity/bounty are represented, leaving the agent to infer behavior from the schema defaults.

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 short sentences, front-loaded with the resource and followed by the alternate mode. There is no filler, though it is arguably terse to the point of under-specifying pagination.

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?

An output schema exists, so return-shape explanation is not strictly needed, and the description does hint at returned fields. For a simple read tool this is close to adequate, but with zero schema coverage and no annotations, the absence of any pagination or auth context leaves a real 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 description coverage is 0%, so the description must compensate, but it only explains `report_id` (selects a single report). The `page` and `limit` parameters are entirely undocumented in both schema and description, so an agent gets no guidance on pagination semantics.

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

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

The description names a concrete resource — the caller's own submitted reports — and even lists the salient fields (state, severity, bounty), which separates it from sibling listing tools like search_disclosed_reports or hacktivity_search. It stops short of explicitly naming those siblings, so the distinction is inferable rather than stated.

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 one clear mode switch — 'Pass `report_id` for one report' — which tells the agent how to go from list to single-item retrieval. However, it never says when to prefer this over the sibling discovery tools or what happens when no report_id is supplied, so usage remains 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one trait, program-scoped deduplication, but says nothing about permissions/auth, rate limits, pagination, or result ordering for a search endpoint.

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?

It is a single compact sentence with no waste, and the scoping constraint is front-loaded. The terseness crosses into under-specification, but it is not verbose or padded.

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?

An output schema exists so return values need not be described, but with no annotations and 0% parameter documentation, the agent is missing essential invocation context such as query semantics, default result size, and how this differs from hacktivity_search.

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 0% across three parameters. The description implies the program handle is required ('one program') but adds no meaning for 'query' or 'limit', leaving two of three parameters undocumented in both schema and 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 names the resource ('disclosed reports') and scopes it to a single program, which separates it from hacktivity_search and my_reports. However, it is a noun phrase with no verb, and 'search' is only inferable from the tool name, so the action itself is implied rather than stated.

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 parenthetical hints that results are deduplicated within the program being hunted, giving a fragment of context, but there is no explicit when-to-use guidance and no mention of the obvious alternative hacktivity_search for broader disclosure browsing.

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