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 the auth mechanism (BIZONE_SESSIONID / BIZONE_COOKIE) and a meaningful privacy boundary ('reports themselves are never exposed'), which prevents an agent from expecting report data. It stops short of describing behavior when no session is configured or any error/failure mode.

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

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

Two sentences, front-loaded with the resource and its data source, followed by the privacy caveat. No filler or redundancy.

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

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

With no output schema and no annotations, the description compensates by enumerating the returned fields (username, reputation, resolved reports, rewards, verification state). The main remaining gap is undefined behavior when the session is missing or invalid.

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 4 applies. The mention of session env vars is a useful hint that the caller's context, not an argument, drives the result.

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 (returns the profile of the session-configured account) and enumerates the fields returned. It implicitly distinguishes itself from get_researcher by scoping to the authenticated account, though it never names that 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?

Usage is only implied: an agent can infer this is the way to identify the current account, but there is no explicit 'use this when...' guidance or pointer to get_researcher for other users. No exclusions or prerequisites are stated beyond the session env vars.

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 exist, so the description must carry the burden, and it does disclose the returned content in concrete terms (payout ranges, statistics, 90-day numbers, average answer time, rules markdown, scope summary) plus the flexible identifier forms. It omits what happens when a name fragment is ambiguous or matches multiple programs, and gives no indication of cost/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?

Two sentences, front-loaded with the tool's identity and contents, then identifier flexibility. 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?

With no output schema, the description usefully enumerates what is returned, and the schema covers all parameters. The remaining gap is edge-case behavior (ambiguous fragment, not-found handling) for a read tool that has no annotations to fall back on.

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 all four parameters are already documented in the schema. The description's 'accepts a slug, part of the name, or a ... URL' largely restates the schema's program parameter, adding no syntax or matching-behavior detail beyond it.

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 ('Full profile of one bug bounty program') and enumerates what the profile contains, so an agent can distinguish it from program_stats and get_program_scope 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?

Usage is implied by 'one program' and the field list, but there is no explicit guidance on when to prefer list_programs, program_stats, or get_program_scope, and no exclusions. The only routing hint (use get_program_scope) lives in the schema, not the description.

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 does disclose the return surface (severity, target/notes, eligibility, archive status) and that the result is exhaustive. However, it says nothing about result size, pagination, auth requirements, or whether archived items are excluded by default beyond what the schema already states.

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, zero waste, with the scope of what is returned front-loaded ahead of the advisory usage note. Every clause carries 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?

With no output schema, the description appropriately enumerates the returned fields so an agent knows what comes back. It is nearly complete for a read-only listing tool, missing only volume/pagination expectations and permission notes.

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 four parameters (program, severity, in_scope_only, include_archived) are already documented in the schema with defaults. The description adds only the useful note that target/notes is 'often a URL or domain', which is marginal field-level context rather than parameter guidance.

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 resource and scope: the complete in-scope/out-of-scope asset list for a BI.ZONE program, plus the fields each asset carries. An agent can distinguish it from get_program (metadata) or search_scope (filtered lookup), though neither sibling is named 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?

'This is the authoritative list to check before testing a target' gives an implied usage context, but there is no explicit guidance on when to prefer search_scope or get_program, and no exclusion criteria. The agent must infer the 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 full burden and does disclose a genuinely non-obvious access-control behavior: private/internal reports expose only metadata unless the server has a session cookie. It does not cover not-found behavior or error responses, but the disclosure of restricted-visibility handling is substantive and cannot be inferred from structured fields.

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, zero waste, with the payload contents front-loaded and the visibility caveat as the closing qualifier. Nothing is repeated from the title or schema.

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 one-parameter read tool with no output schema and no annotations, the description compensates well by enumerating the returnable fields and flagging the metadata-only case. The only gap is failure behavior (nonexistent id, unauthorized access), which an agent would likely want before calling.

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 parameter with 100% schema description coverage, including its provenance ('as returned by list_reports') and positive-integer bound, so the schema does the heavy lifting. The description only restates 'by id' and adds no format or resolution guidance beyond it.

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 ('Details of one BI.ZONE report by id') and enumerates the fields returned (researcher, program, asset, payout, visibility, dates). The 'one ... by id' framing makes it clearly distinct from the list_reports sibling without needing the 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?

Usage is only implied: the id comes from list_reports (stated in the schema, not the description). The description does add a real access condition — private/internal reports return metadata only unless a session cookie is configured — but it never says when to prefer this over list_reports or what to do when a lookup is not permitted.

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 full disclosure burden. It does establish that the data is 'public' (implying no special auth) and that this is a retrieval operation, but says nothing about failure modes — invalid username, nonexistent profile — or whether the result is cached/truncated. For a low-risk read this is adequate but not rich.

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, zero filler: the first front-loads what the profile returns, the second handles the accepted input formats. The enumerated field list is long but each item is meaningful content an agent might select on. Slightly dense but well-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?

There is no output schema, so the description usefully compensates by enumerating the returned sections (rank, reputation, reports/rewards, achievements, payout breakdown). Combined with the fully-covered input schema, an agent has enough to decide and call correctly; only error behavior and the effect of the include_* flags on the payload are unaddressed.

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 four parameters (researcher, reports_limit, include_reports, include_achievements) are already documented in the schema, including defaults of 10 and true. The description's example values ('Santry', the full URL) add a little concrete guidance but mostly restate the schema. Baseline 3 is correct.

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 uses a specific verb+resource ('Full public profile of a BI.ZONE researcher') and enumerates exactly what the profile contains: rank, reputation, reports, rewards, achievements, payout breakdown. An agent can immediately tell this is a per-researcher lookup rather than a listing tool. It stops short of naming which sibling to use instead when the agent wants its own profile (get_me) or a leaderboard (top_hackers).

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: the accepted-input sentence ('username or a profile URL') signals this fetches one known researcher, which implicitly rules out search/listing scenarios. There is no explicit 'use this when X, use get_me when Y' routing against the ten sibling tools, so an agent must infer the boundary itself.

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 disclosure burden and does reasonably well: it lists concrete return fields (slug, name, report counts, payouts, scope size, max critical reward) and the downstream hand-off. It omits pagination behavior, auth requirements, and rate limits, but the read-only nature is inherent to 'List' and the main behavioral shape is conveyed.

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 tight sentences with zero filler. The core purpose and returned fields come first, followed by the actionable next step, so the 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?

No output schema exists, and the description compensates by enumerating the key returned fields, which is exactly what an agent needs. Given the tool is a simple read-only list with fully documented params, the only minor gap is pagination/return-shape detail.

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%, with every parameter (sort enum, limit, offset, search) documented in the schema itself including defaults and examples. The description adds no parameter-level detail beyond that, 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?

States a specific verb and resource ('List and search bug bounty programs (companies)') and names the platform. It also enumerates the returned fields and names the sibling tools that consume the resulting slug, so an agent can tell it apart from get_program, program_stats, and search_scope without opening schemas.

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 tells the agent what to do *after* calling ('Use the returned `slug` with get_program / get_program_scope / list_reports'), which is useful downstream routing. However, it never states when to choose this tool over siblings like program_stats or search_scope, nor any exclusions or prerequisites, so usage is only 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?

Without annotations, the description carries the burden and does disclose a key behavioral constraint: the configured account's own reports are never returned. It also indicates the returned content at a high level (who reported, program, date, payout), though it does not explicitly state read-only status, auth needs, 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 front-loaded with the main purpose, then filters, use case, and the important exclusion. Each sentence adds useful information with 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?

Given nine fully documented parameters and no output schema, the description is largely complete: it explains scope, filters, intended use, returned content at a high level, and the self-report exclusion. Minor gaps remain around pagination behavior and explicit read-only semantics, though the schema covers limit and offset.

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 nine parameters are already documented in the schema. The description mentions filtering by program, researcher, price range, and date, but adds no syntax or format details 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 states a specific verb and resource: browse bug bounty reports of other researchers. It clarifies the scope by saying reports of the configured account itself are never returned, which distinguishes it from account-oriented siblings like get_me and from single-report 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?

It gives a clear intended use case: studying what gets paid on a program, and mentions available filters. It does not explicitly name alternatives such as get_report or program_stats, nor does it state 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?

No annotations are supplied, so the description bears the full burden. It conveys read-only aggregation over 'visible' reports and reveals the shape of the computed output, but says nothing about permissions, cost/rate limits, caching, or whether 'visible' depends on the caller's access level.

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 dense sentence with the resource front-loaded and the output contents enumerated after the colon; nothing is wasted. It is long but every clause is informative, so it stops just short of maximal efficiency.

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

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

With no output schema, the description usefully sketches the return contents (yearly and severity breakdowns, top researchers), which is the main thing an agent needs. Minor gaps: no mention of what 'visible' means or of response size/pagination, but the core is covered.

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%, with both `program` (slug/fragment/URL accepted forms) and `years` (1-20, default 6) fully documented in the schema. The description adds no further parameter semantics beyond hinting at the yearly breakdown, 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 opens with a specific verb+resource ('Aggregated statistics computed from all visible reports of a program') and then itemizes exactly what is aggregated: totals/averages of payouts, reports, money per year, per asset severity, and top researchers. This clearly separates it from siblings like list_reports or top_hackers, though no sibling is named 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?

Usage is only implied: 'all visible reports of a program' suggests this is the roll-up view over a program's report corpus, in contrast to per-report tools. There is no explicit when-to-use/when-not guidance and no named alternative (e.g. 'use get_program for metadata, this for aggregates').

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 present, so the description carries the full burden. It does disclose the return shape at a high level ('which program owns each asset and whether it is in scope'), confirming read-only search semantics. However, it says nothing about pagination limits, filtering defaults (in_scope_only defaults true), or result ordering, all of which matter for a 5-param search.

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

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

Two sentences, front-loaded with the action and scope, with no filler. The final sentence partly restates the return-ownership point already made, so it is slightly redundant but not wasteful.

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 a fully documented schema and no output schema, the description covers what an agent needs: what is searched, what comes back, and the primary use case. The missing pieces (pagination behavior, result ordering) are secondary for a straightforward search 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%, so all five parameters are already documented in the schema, including defaults for limit, offset, and in_scope_only. The description's examples ('kaspersky.com', 'vpn', 'mobile app') add only marginal flavor beyond the schema's substring semantics. 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?

States a specific verb+resource (search scope assets) and scopes it explicitly to all programs, which separates it from the per-program get_program_scope sibling. It also names the match fields (domain, product name, description). It stops short of explicitly naming get_program_scope as the alternative.

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?

'Useful to find every program that covers a given domain' gives one concrete use case, so usage is implied rather than spelled out. There is no when-not guidance and no explicit routing to get_program_scope for single-program lookups.

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, so the description carries the burden and does well: it discloses the rating formula (running sum of accuracy points, signal −10…+7, impact 0…50), that program-mode excludes the authenticated account, and what fields each mode returns. Auth requirements and pagination semantics beyond schema are not restated, which keeps it short of a 5.

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?

Mode split is front-loaded and sentences are dense with information rather than filler. The rating-formula detail is slightly tangential to invocation but legitimately explains sortable 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?

With no output schema, the description supplies the returned fields for both modes, which is what an agent needs to interpret results. Defaults and paging live in the schema, so the remaining gap is minor.

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, but the description adds real meaning: `program` is not just a filter but switches the entire computation and output shape (reports count, total and best payout), and `search` is implied as username filtering. This is genuine semantic value beyond the schema text.

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 ('researcher leaderboard') and clearly splits two modes: global ranking without `program`, per-program ranking with it, naming the exact metrics returned in each mode. An agent can distinguish it from `get_researcher` and `program_stats` without opening a 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?

Explicitly names the condition that switches behavior ('Without `program`… With `program`…') and routes to the alternative tool ('Use `get_researcher` for a full profile'). The when-to-use decision is fully spelled out.

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