Bounty Operator

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds behavior beyond them: the required connection token in the Authorization header and the exact information returned. That auth requirement is genuinely useful operational context, though rate-limit/expiry behavior beyond the reset time is not discussed.

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, front-loaded with the 'call before run_review' trigger, then the return payload, then the auth requirement. No filler or repetition; each sentence carries distinct 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them. Combined with the auth requirement and the sibling sequencing, an agent has everything needed to call this correctly before run_review.

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. The mention of an Authorization header is not a schema parameter but does clarify the calling precondition, adding modest value with no parameter semantics to explain.

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

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

The description names a specific resource and scope — the plan, hosted reviews used today, concurrency limit, and reset time — and explicitly positions the tool relative to run_review. An agent can tell this is a read-only allowance/quota check and not a review-execution tool 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?

It gives a concrete trigger: 'Call before run_review to check the allowance,' which is a real sequencing instruction naming the sibling it precedes. It stops short of stating when not to call it or what to do with the returned numbers, so no exclusions are offered.

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=false, so safety is covered. The description adds real value beyond that: it discloses the internal verification behavior (every cited file and line checked against the manifest) and the auth posture ("No account needed"), which an agent cannot infer from 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?

Two tight sentences: the first front-loads when to call it and what it reads, the second states the verification behavior and the return value. No restatement of the tool name or 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 the return values need not be spelled out, yet the description still names them for orientation. Combined with the outlined read/verify flow and the no-account note, an agent has enough to invoke it correctly; only explicit sibling differentiation 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 100%, so the baseline is 3. The description adds a small pointer for `context` ("the same context object prepare_review takes") and frames `manifest` as what "prepare_review or run_review returned, unchanged," but the remaining six parameters (model, source, stages, profile, provider) get no additional meaning from the prose.

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 chain (reads, checks, returns) over a named resource (the review vs. the manifest), and it explicitly states the output artifacts: verdict, reference problems, and the Markdown evidence packet with hashes. It is clearly distinguishable from prepare_review and run_review by naming the upstream tool it depends on.

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?

"Call after writing a review from prepare_review" gives a concrete sequencing prerequisite that tells the agent where this sits in the workflow. It lacks explicit when-not-to-use guidance or a direct comparison against run_review/run_gauntlet_plan, so it stops short of full routing guidance.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds useful context: no account needed, what fields each profile carries, the gauntlet stage order, verdicts per mode, and the hosted/core split. It stops short of describing pagination or output shape, but the output schema exists and covers that.

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 sentences, front-loaded with the call-first directive and then progressively detailing return contents and the hosted/core routing. Slightly dense – a couple of the enumerated fields could be trimmed – but nothing is filler.

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

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

For a zero-param discovery tool with an output schema and full annotations, this is complete: it says when to call, what comes back, and how the result routes into the two sibling tools that actually run reviews.

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?

Zero parameters, so baseline is 4. Description correctly implies a parameterless enumeration and even states what it feeds into run_review (provider and model ids), which is meaningful context beyond 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?

Specific verb+resource ('list review profiles') and explicitly frames itself as the discovery/first-call tool, distinguishing it from siblings run_review and prepare_review by describing what it returns and how those siblings consume hosted vs core profiles.

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?

Front-loads 'Call first when you do not know which review fits' – an explicit when-to-use rule. Also routes downstream: hosted profiles → run_review, core profiles → prepare_review, which tells the agent what to do after this call.

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, non-destructive, closed-world), and the description adds substantial context beyond them: file contents are not sent back, secrets are scanned and can block, blocked results list file/line/kind, and hosted profiles are rejected with a specific error code. That is exactly the layered disclosure this dimension rewards.

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 trigger and the effect, and every sentence carries operational information (scan behavior, return payload, refusal code, no account). It is dense rather than padded, though the profile listing sentence is the weakest link since the enum is broader.

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 6-parameter tool with nested objects and an output schema, the description covers trigger, side effects, refusal path, return contents, and cost/auth posture. Return values need not be explained further because an output schema exists, so nothing essential 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 100% and every parameter, including the nested context object, is documented in the schema itself. The description adds only marginal value (mode defaults to bounty, the three core profiles), and it names fewer profiles than the enum actually contains, so it neither compensates for nor enriches the schema meaningfully. Baseline 3.

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 ('prepare a review', 'scans the files for secrets') and precisely distinguishes itself from run_review by explaining that hosted profiles are refused here with code hosted_profile. An agent can place it against its siblings 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?

Explicit timing ('Call before reviewing code or a draft report with your own model'), an explicit alternative ('run it with run_review'), a pointer to list_profiles for the profile ids, and a stated precondition ('No account needed') plus the acknowledgeWarnings escape hatch. Nothing is left 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?

Far exceeds what the annotations provide. It discloses quota consumption ('Uses one hosted review'), billing/refusal semantics (refused=true, blocked, provider_policy failures not counted), failure codes (operator_only), latency, required auth headers, and a safety directive to treat review text as data and not to re-run a declining model.

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?

Dense but front-loaded: purpose and return list lead, then constraints, then failure semantics. Nearly every clause carries actionable information, though the enumeration of returned artifacts partially duplicates the output schema and the paragraph runs long.

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 call that has quota cost, plan gating, multiple refusal paths, header-based auth and multi-minute latency, the description covers all the behavior an agent needs; the return artifacts are documented by the output schema, so nothing critical 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 coverage is 100%, so the baseline is 3, but the description adds auth-relevant context the schema cannot carry: the provider key travels in the X-Provider-Key header and the connection token in Authorization. It also notes that 'context' is the same object prepare_review takes, tightening cross-tool parameter understanding.

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?

Opens with a specific verb+resource ('Runs the review') and names the inputs that bind it (provider, model, X-Provider-Key header). It explicitly positions itself against siblings by stating it is 'the only way to run a hosted one,' which an agent can act on without opening the other 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?

Gives strong operating conditions: the verdict/panel profiles require an Operator plan, a free account is refused with operator_only, refused model output must not be re-run, and calls can take several minutes. It does not explicitly name prepare_review or build_packet as the alternative for a preview pass, so routing against siblings is implied rather than spelled out.

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