rea-captcha

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

Annotations already establish readOnlyHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: this is adapter-free and stateless, neither controlling nor preserving a browser session — exactly the trait that separates it from the browser-driving siblings. It stops short of stating cost, limits (e.g. the 2MB/500KB caps), or rate 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 tight sentences, front-loaded with the input scope before the environment caveat, with no filler. Slightly under-specified rather than padded, but structurally sound.

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 carries the full burden of describing what the analysis returns — and it says nothing about the result shape, verdict, or confidence. For a 5-parameter tool with 20% schema coverage and no return documentation, an agent cannot predict the response, which is a material gap.

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

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

Schema coverage is only 20% (only 'url' is documented), so the description has to compensate — and it does partially by naming all five inputs (URL, title, HTML, text, runtime signals), which helps the agent map arguments. It adds no semantics about form, precedence, or how runtime_signals strings should look, so it lifts the baseline only modestly above 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 clear verb ('Analyze') and enumerates the input resource types (URL, title, HTML, text, runtime signals), so the agent knows what it operates on. However, it never says what the analysis is *for* — no mention of CAPTCHA classification, scoring, or verdicts — and gives no basis for distinguishing it from the sibling captcha_inspect, whose purpose overlaps.

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

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

The phrase 'already available to the calling agent' plus 'needs no configured browser adapter and does not control or preserve a browser session' implicitly tells the agent when this fits: when it already holds page evidence and has no live browser session. But there is no explicit when-to-use/when-not statement, and no routing against captcha_inspect or captcha_wait, which is the main selection risk.

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 the non-read-only, non-destructive, open-world profile. The description adds that it acts in an existing browser session and then waits for 'fresh server-validated evidence', which hints at post-action polling/verification. It does not disclose failure behavior, what state is altered, or what happens if authorization is not held.

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 action front-loaded and no filler. It is dense with qualifiers ('authorized provider-test or owned-origin'), but it is appropriately sized for the 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?

With three parameters, 33% schema coverage, no output schema, and an open-world non-read-only action, the description leaves too much unspecified. It never explains what 'fresh server-validated evidence' means as a result, nor how poll_ms/timeout_ms govern the wait.

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 only 33% – only session_id is documented. The description adds nothing about poll_ms or timeout_ms, so their units, defaults, and effect on the wait-for-evidence behavior are undocumented in both schema and description. It 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?

The verb is 'complete' and the object is a challenge within an 'existing browser session', which is a recognizable action. However, the hedged phrasing 'authorized provider-test or owned-origin challenge' obscures that this is a CAPTCHA-solving tool and does nothing to separate it from siblings like captcha_handoff or captcha_resume.

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 authorization boundary ('authorized provider-test or owned-origin') implies when this tool is permitted, which is meaningful usage context. But it names no alternative and gives no condition for choosing it over captcha_handoff, captcha_resume, or captcha_wait, leaving the routing decision 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=false and openWorldHint=false, so the mutation/session-bound nature is covered structurally. The description adds the useful nuance that it only marks state in the existing session rather than performing the handoff itself, but says nothing about what happens next (session pause, timeout, or required follow-up call).

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 phrase 'in the existing browser session' earns its place by ruling out new-session behavior.

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 state-change tool with annotations covering safety and no output schema, this is close to adequate. However, in a sibling set that includes captcha_wait and captcha_resume, the description leaves the post-handoff lifecycle (does the agent wait, resume, or stop?) unspecified.

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

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

Only one parameter and schema description coverage is 100%, so the schema fully documents session_id. The description adds no syntax, format, or sourcing detail beyond what the schema provides, which is the expected baseline.

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 (mark) and a specific resource (the current challenge) with the resulting state (awaiting a person). An agent can tell it apart from captcha_inspect/analyze, though it never explicitly contrasts itself with the other captcha siblings.

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

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

The phrase 'awaiting a person' hints at the scenario, but there is no explicit when-to-use, when-not-to-use, or relationship to siblings like captcha_wait or captcha_resume. An agent must infer when handoff is preferable to waiting or resuming.

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 and openWorldHint=false, so the safety profile is covered. The description adds that it returns 'evidence plus the handling policy,' which hints at a diagnostic, non-mutating read, but neither term is defined and nothing is said about whether inspecting consumes or alters session state. Some added value over the annotations, but 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 sentence that front-loads the verb and scope and ends with what the caller gets back. No filler, no restatement of the title.

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 carries the burden of explaining the return, and 'evidence plus the handling policy' is left undefined — an agent cannot tell what evidence is provided or what it is supposed to do with the policy. The relationship to the five sibling captcha tools is also unstated, leaving the selection decision under-informed.

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?

Only one parameter, and schema description coverage is 100% ('Configured browser session identifier'), so the schema fully documents session_id with its length bounds. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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 (inspect), an explicit resource (a configured browser session), the search target (an active verification challenge), and the return payload (evidence plus handling policy). It reads as a read-only probe, which distinguishes it reasonably well from captcha_complete/handoff/resume, though the boundary with the similarly-named captcha_analyze is never addressed.

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 first-look check to discover whether a challenge exists before acting. There is no explicit when-to-use, no statement of when NOT to call it, and no routing to captcha_analyze, captcha_wait, or the other siblings despite five overlapping alternatives.

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 declare readOnlyHint=false and openWorldHint=false, so the agent already knows this mutates local state; the description's 'resume its agent lifecycle' is consistent with that. It adds the re-inspection behavior but says nothing about permissions, idempotency, or what happens if the challenge is in fact not clear, so beyond-annotation value is modest.

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 tight sentence with the action front-loaded and the precondition trailing, with no filler. It could be marginally more efficient by naming the gating action/alternative, but there is no wasted wording.

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, no-output-schema tool the description covers the essentials, and annotations carry the safety profile. But among six near-identical captcha siblings, it fails to state how this differs from captcha_inspect or captcha_wait, and is silent on failure behavior, which is exactly the gap that matters here.

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 one parameter at 100% schema description coverage, the schema already documents session_id fully. The description's phrase 'existing browser session' only loosely reinforces that the id must refer to a live session, adding no real syntax or format detail beyond the schema — the baseline 3 applies.

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

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

The description pairs a specific verb ('re-inspect', 'resume') with the resource ('existing browser session', 'agent lifecycle'), which is clearer than a bare name restatement. It gestures at the difference from captcha_inspect via 're-inspect', but never names or contrasts with any sibling explicitly, 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?

The precondition 'only after the challenge is clear' supplies an implied when-to-use condition, which is better than nothing. However, it does not say what to do when the challenge is not yet clear (captcha_wait, captcha_handoff, captcha_complete are all plausible alternatives) and names no alternative tool, leaving routing 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=true and openWorldHint=false, so the safety profile is covered. The description adds real behavior beyond that: it polls repeatedly rather than checking once, it operates on the same session (stateful coupling to prior calls), and it is bounded by a timeout. It never says what happens on timeout expiry (error vs. negative result), which is the key outcome for a polling tool.

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

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

A single tight sentence with no filler, front-loading the action (poll the same browser session) before the exit conditions. Nothing redundant, though it could have used the remaining space for the sibling routing it lacks.

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, so the description should carry the result semantics, and it does not: an agent cannot tell whether an expired timeout raises an error or returns a cleared/not-cleared status. For a 3-parameter polling tool with documented siblings, this leaves a meaningful gap despite the accurate behavioral summary.

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 only 33% (session_id alone is documented), so the description must compensate somewhat. It clarifies that the session must be the same one already in use and that the wait is time-bounded, which maps to session_id and timeout_ms, but poll_ms is left entirely unexplained in both the schema and 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?

States a specific verb (poll/wait) and resource (the same browser session's verification challenge) plus its termination conditions, so the action is unambiguous. It does not distinguish itself from siblings like captcha_inspect or captcha_resume, which an agent could plausibly confuse with 'wait for the challenge to clear.'

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

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

Usage is only implied: 'the same browser session' hints this follows a prior captcha interaction, but there is no explicit when-to-use, when-not-to-use, or naming of alternatives such as captcha_inspect (check state) or captcha_resume. With five captcha siblings, routing guidance is the main missing piece.

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