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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the check is performed by making a live API request for one program, so the agent understands it consumes a network call and depends on external state rather than inspecting a local file.

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 front-loaded sentence, no filler, and the mechanism follows the purpose immediately. Every clause 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?

With an output schema present, return-value details (e.g. what a failed check looks like) need not be restated, and with zero parameters there is no input to document. The only remaining gap is any credential/permission prerequisite or rate-limit note, which is minor for a read-only diagnostic.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. Nothing in the description contradicts the empty 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 verb and resource (check the stored HackerOne API token) and even the mechanism (by requesting one program), which no sibling tool does — siblings are all list/get data-retrieval tools. It's clear what the tool accomplishes without needing the schema, though it doesn't explicitly name a sibling it contrasts with.

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?

Usage is implied — you call this to validate that stored credentials still work — but there is no explicit statement of when to use it, when not to, or what to do instead if the check fails. Adequate but leaves the trigger condition 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the useful detail that the balance is scoped to the authenticated hacker and reflects 'current' state, but nothing about freshness lag or failure modes.

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 sentence with the resource and scope front-loaded and no filler. Every word 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 trivial no-param read with an output schema that documents the return shape, the description covers what is needed. Only marginal value (e.g., currency or balance semantics) is absent.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. Schema coverage is 100% and no syntax or format detail is 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?

States a specific verb ('Get') and resource ('payments balance') scoped to the authenticated hacker, which is enough to distinguish it from list_earnings and list_payouts. It does not, however, explicitly contrast itself with those siblings, so an agent must infer the distinction.

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?

Usage is only implied: call it when you need the current balance. There is no statement of when to prefer it over list_earnings/list_payouts, and no exclusions or prerequisites beyond the word 'authenticated'.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is fully covered. The description adds that the response includes policy and a named set of declaration flags, which is useful semantic context, but an output schema exists so return content is largely redundant. No auth, rate-limit, or error behavior is disclosed.

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 core purpose is front-loaded in the first sentence, and the supplemental detail (flag names, parameter provenance) follows in short, scannable sentences. The enumeration of five declaration flags is slightly list-heavy but each name earns its place by defining expected response fields.

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 read tool with an output schema and full annotation coverage, the description supplies what the schema and annotations do not: the meaning of the handle argument and the identity of the declaration flags. Auth and pagination are non-issues for a one-record fetch. Nothing critical an agent needs to call it correctly is missing.

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 the single required parameter, so the description must carry the burden. It does: it explains that handle is the program handle sourced from list_programs and gives a concrete example value ('security'). That is meaningful semantics beyond the bare 'Handle' title in 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 opens with a specific verb+resource: 'Get one program, including its policy and declaration flags.' This clearly distinguishes a single-record fetch from the sibling list_programs, which is named as the source of the handle. It stops short of an explicit contrast sentence ('unlike list_programs, this returns full detail'), but the differentiation is readily inferable.

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 against alternatives like list_programs. The only practical direction is that the handle comes from list_programs, which implies the call sequence but leaves the choice to the agent. Usage is implied rather than 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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real value on top: it enumerates the payload shape, flags the conditional presence of vulnerability_information when the hacker owns the report, and draws a clear boundary that attachment bytes are not downloaded (only expiring metadata URLs).

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-loaded with the core action in the first sentence, then two supporting sentences. The long field enumeration (reporter, program, weakness, severity, bounties, swag, activities...) partially duplicates the existing output schema, which is the only mild inefficiency.

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 fully restated, and annotations carry the safety profile. The description still covers the meaningful behavioral nuances — conditional vulnerability_information and the no-attachment-download boundary — leaving only minor gaps like error behavior for unauthorized report ids.

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 a single required parameter (report_id) with 0% schema description coverage, so the description must compensate and largely does not — it never states what a report id is, where to obtain it, or whether it must belong to the caller's account beyond the vague 'the account can view' scope.

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 with scope: 'Get one report the account can view.' The singular 'one report' implicitly distinguishes it from list-style siblings like list_my_reports, but no sibling is named explicitly, so it stops short of a 5.

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?

Usage is only implied — an agent infers this is the detail-fetch tool for a single report versus the list and intent tools. There is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., get_report_intent) 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safe-read profile is covered. The description's 'does not submit or update' adds mild clarification about the intended read-only fetch semantics, but no additional behavioral context beyond annotations.

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

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

Two short sentences with the core action front-loaded and no wasted text. The second sentence is a useful scoping caveat rather than 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?

An output schema exists so return values need not be explained, and annotations carry the safety profile. For a simple single-parameter getter the description is nearly sufficient, with the only gap being the undocumented identifier parameter.

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 parameter (report_intent_id) at 0% schema description coverage, so the description must compensate and it does not. Nothing explains what the id refers to or where it comes from, leaving the parameter undocumented in both places.

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 (get) and resource (report-intent draft) with singular scope, which implicitly distinguishes it from the sibling list_report_intents. It is clear what it does, though it does not explicitly contrast itself with siblings like get_report.

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 clause 'This does not submit or update it' hints at usage boundaries but frames it negatively rather than saying when to use this versus list_report_intents or the submission flow. Usage is implied rather than 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful scoping fact that results are limited to the authenticated user's own earnings, but says nothing about pagination behavior, ordering, or result size.

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 sentence with zero waste that front-loads the verb and resource and clarifies the key term in a parenthetical. Nothing redundant is included.

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. However, the absence of any pagination guidance for two paging parameters and the lack of differentiation from get_balance/list_payouts leave real gaps for a tool an agent must select among siblings.

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 both page_size and page_number are undocumented in the schema, and the description does not compensate at all. It never mentions pagination, defaults, or max page size, leaving the agent to infer the meaning of both parameters.

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

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

States a specific verb (List) and resource (earnings), and usefully disambiguates the vague term 'earnings' as bounties, retests, and pentests, scoped to the authenticated hacker. It does not, however, differentiate itself from overlapping siblings such as get_balance or list_payouts.

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

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

No guidance on when to use this versus the closely related get_balance and list_payouts tools, which an agent must choose between. The scope note ('authenticated hacker') is the only context offered; there are no exclusions or conditions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds the meaningful data-scope caveat that this page omits report activity and defines pagination start/limit. It doesn't discuss ordering or total counts, but the added constraints go beyond the annotations.

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

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

Three short sentences with zero waste; the core purpose is front-loaded, followed by the scope caveat and the alternative tool. 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?

An output schema exists so return values need not be described; combined with the annotations, the description covers what the tool returns (a paginated, activity-free list of the caller's reports) and how to paginate. Nothing an agent needs to invoke it correctly is missing.

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 carry the burden, and it does supply real semantics: page_number is 1-based and page_size is bounded 1-100. It omits the default of 25 and any ordering implications, so it compensates substantially but not fully.

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

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

States a specific verb (List) and resource (reports) plus the scope qualifier 'submitted by the authenticated hacker', which distinguishes it from sibling report tools like get_report and get_report_intent. It also explicitly names get_report as the tool for the full report.

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

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

Explicitly routes the agent to get_report when the full report (including report activity) is needed, and explains that this listing excludes that activity. Clear context, though it doesn't mention other siblings such as get_report_intent or list_report_intents.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the ownership scoping ('authenticated hacker'), but says nothing about pagination behavior or result ordering beyond what annotations imply.

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 zero filler, though it is arguably too terse for a paginated list tool.

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 annotations cover safety. However, the two undocumented pagination parameters and the absence of any usage context leave the definition 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% and the description names no parameters at all, leaving page_size and page_number (with their defaults) unexplained in prose. With low coverage the description was expected to compensate and does not.

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 ('List payouts') with an ownership scope ('sent to the authenticated hacker'), which lets an agent distinguish it from list_earnings and get_balance. It does not explicitly name or differentiate from any sibling, so it stops short of a 5.

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 indication of when to use this tool versus list_earnings, get_balance, or search_hacktivity, and no prerequisites or exclusions are stated. The agent must infer usage purely from the name.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely new context beyond that: program policies are omitted from the results, and pagination boundaries (page_number starts at 1, page_size 1-100) constrain 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?

Four short sentences, front-loaded with the purpose, then the omission caveat and the alternative, then the pagination constraints. Every sentence carries information; nothing is 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?

An output schema exists, so return values need not be explained, and the description covers the remaining gaps an agent would care about: what is excluded from the listing, where to get the excluded data, and how paging behaves.

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 carries the full burden and does compensate for both parameters by stating the page_number origin (1) and the page_size valid range (1-100). It omits the stated defaults (25 and 1), which are visible in the schema, so it is not quite exhaustive.

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 gives a specific verb+resource ('List programs') plus a clear scope ('the hacker account can access'), which is more than a restatement of the name. It also draws a boundary against get_program by noting that policies are omitted here, though it does not differentiate itself from the other list_* 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?

It explicitly routes the agent: if you need the program policy or declaration flags, call get_program instead. That is a concrete use-vs-alternative rule. It stops short of stating when this tool is preferred over the other list_* tools or any prerequisites.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond them: the response contains expiring download URLs (implying time-sensitivity) and that no file bytes are transferred — a meaningful distinction for an agent that might otherwise expect content.

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 with zero filler; the primary purpose is front-loaded and the clarifying exclusion follows. 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?

An output schema exists, so return-value explanation is unnecessary, and the description covers the behavioral essentials for a one-parameter read tool. It is only marginally incomplete — no mention of pagination, ordering, or empty-result behavior for a metadata list.

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

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

Schema description coverage is 0% and the description never mentions report_intent_id, so it adds no meaning over the schema. The single parameter is largely self-explanatory by name, which keeps this at a baseline 3 rather than lower.

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 (List) and resource (attachment metadata for a report-intent draft), and preemptively rules out the adjacent operations (downloading bytes, uploading attachments). No sibling tool covers attachments, so the scope is 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?

Gives clear context for use (attachments of a report-intent draft) and explicitly states the two things it is not for, which steers the agent away from download/upload operations. It stops short of naming an alternative tool to use for those operations, so no explicit when-instead 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real context beyond them: the listing is restricted to *unsubmitted* drafts owned by the authenticated user, and it explicitly rules out submission. Pagination and ordering behavior are still unstated.

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 scope, with no waste. The second sentence is slightly redundant against readOnlyHint/non-destructive annotations, which keeps it from a 5.

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-value detail is unnecessary, and the description covers the crucial scoping (auth user, unsubmitted state). Given the sibling list contains many list_* tools, a bit more differentiation (e.g., versus list_report_intent_attachments) would fully close the 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no argument semantics to document and the description correctly spends no space on them.

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?

Specific verb+resource ("List ... report-intent drafts") with two scoping qualifiers that separate it from siblings: "unsubmitted" and "owned by the authenticated hacker". An agent can distinguish it from get_report_intent (single item) and list_my_reports (submitted reports) without opening any schema.

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 qualifiers imply when this tool applies, but no alternative is named and no explicit when-to-use/when-not condition is stated. "This does not submit them" is a side-effect clarification rather than routing guidance, 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds no behavioral context beyond the purpose statement, such as what the exclusions represent or how they relate to the program's reward rules.

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 scoping qualifier is placed where it matters. It is efficient, though it is so terse that it omits useful detail rather than being optimally sized.

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. However, with one required parameter undocumented and no usage guidance against siblings, the definition is only minimally complete for an agent to invoke it confidently.

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

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

Schema description coverage is 0% and the description never explains the required 'handle' parameter. The phrase 'a program excludes' weakly implies handle identifies the program, but no format, source, or lookup guidance is given, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (List) and resource (report categories a program excludes from rewards), and the qualifier 'beyond core ineligible findings' scopes it away from the baseline ineligible list. It is clear what the tool returns, though it does not explicitly name the closest sibling (list_structured_scopes) for contrast.

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 statement of when to call this versus list_structured_scopes or the other scope-related siblings, and no prerequisites or exclusions. The phrase 'beyond core ineligible findings' implies it is an addendum list but leaves the agent to infer when it is the right 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds meaningful non-schema behavior: a 50 req/min rate limit and the 10,000-row page offset ceiling. This goes beyond the structured fields and helps an agent plan calls, though it stops short of describing edge cases or error 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?

Purpose is front-loaded in the first sentence and operational detail follows in a compact second sentence. The enumerated asset fields are somewhat list-like but earn their place by describing returned content; nothing is redundant.

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 need not be explained, yet the description still enumerates the key asset fields, which aids interpretation. Combined with rate-limit and pagination notes, this is complete enough for correct invocation, with only the handle parameter's semantics left implicit.

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

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

With 0% schema description coverage across 6 params, the description must compensate, and it does for the non-obvious ones: id_gt is explained as the last seen scope id for continuation, and created_after/updated_after are flagged as ISO-8601. handle, page_size, and page_number are left to inference, keeping it just short of full coverage.

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

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

States a clear verb and resource ('List a program's structured scope') and clarifies the content is in-scope, submission-eligible assets. It does not explicitly contrast itself with the related sibling list_scope_exclusions, so an agent must infer the boundary, but the core purpose is 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 operational guidance for pagination ('pass id_gt... prefer that over high page numbers'), which is genuinely useful, but it offers no guidance on when to choose this tool versus siblings like list_scope_exclusions or get_program. Usage context is implied rather than 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?

Annotations already declare this a safe, read-only, idempotent, open-world read, so the safety profile is covered. The description adds the pagination bounds ('page_number starts at 1. page_size is 1-100'), which is genuine behavioral context. It says nothing about ordering, total counts, or what 'weakness types' contain, but the output schema carries the return 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?

Two short sentences with no waste, and the purpose is front-loaded ahead of the parameter constraints. It is arguably too terse rather than 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?

An output schema exists, so return values need no explanation, and pagination is covered. However, with 0% schema coverage the undocumented required 'handle' and the absence of any usage context leave real gaps for an agent to call this 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 0%, so the description must compensate, and it only partially does: it clarifies page_number base and page_size range, but the required 'handle' parameter is left entirely unexplained in both schema and description. An agent cannot tell whose program handle is required.

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 ('List weakness types a program accepts'), which is clear and distinct in concept. It does not, however, position itself against the many list_* siblings (list_structured_scopes, list_scope_exclusions, list_programs), so an agent must infer where it fits.

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 the sibling list tools, nor any prerequisites beyond the implicit need for a handle. Usage is only inferable from the name and purpose sentence.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description still adds real behavioral context beyond them: the API's default sort order, the '-' prefix convention for descending sort, and the Lucene query dialect. It omits pagination behavior and result-size limits.

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

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

Front-loaded with purpose, then filters, then sort semantics. Each sentence carries information and there is no filler, though the filter list is a dense run-on that could be formatted more scannably.

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. Query and sort semantics are well covered, and pagination parameters have usable defaults in the schema (25/1). The only real gap is the absence of any explicit pagination semantics, which keeps it from a 5.

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%, so the description must carry the load. It does well for query (Apache Lucene syntax plus a concrete example) and sort (four allowed values, '-' for descending, documented default), but page_size and page_number receive no explanation at all in either the schema or 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 opens with a specific verb and resource: 'Search publicly disclosed hacktivity reports.' The word 'publicly disclosed' implicitly distinguishes it from the account-scoped siblings (list_my_reports, get_report), but no sibling is named explicitly, so it stops short of a 5.

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?

Usage is implied by the filter list and the Lucene example, which tell an agent what can be searched, but there is no explicit 'use this when / use X instead' guidance and no mention of when a scoped tool like list_my_reports would be preferable.

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