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 give readOnlyHint=false (a mutating call) and openWorldHint=false. The description adds real context beyond that: it binds state to a caller-owned task, scopes the handoff to a generation, and requires an existing browser session. It does not say what state the session enters after the handoff, whether the caller must later call captcha_resume, or any timing/auth constraints. No contradiction with 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?

It is a single sentence with no padding, which is good. But it is dense with undefined internal jargon ('generation-scoped', 'caller-owned task') and places the binding clause before the primary action, so the reader must parse twice to find the point.

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?

This is a mutation tool with no output schema and only a readOnlyHint annotation, so the description carries the burden. It omits the handoff lifecycle an agent needs: what the session state becomes, how long the handoff is valid, and how to continue afterward (presumably via captcha_resume). Given the six-tool captcha family, that omission leaves the agent unable to call it correctly in context.

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% across both parameters, so task_id and session_id are already fully documented in the schema. The description mentions the task binding and the existing session but adds no format, validity, or lifecycle detail beyond the schema. 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?

The description states a concrete action (create a human handoff) and the resource it affects (the current captcha challenge, bound to a caller-owned task in an existing browser session). That is more than a restatement of the title. However, it does not distinguish this tool from the five siblings (resume, analyze, wait, complete, inspect), so an agent cannot route between them from this text alone.

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 guidance, no when-not-to, and no mention of any sibling as an alternative. The phrase 'create a generation-scoped human handoff' hints at a workflow state but never tells the agent which conditions should trigger a handoff versus, say, captcha_resume or captcha_wait.

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 only tell the agent this is not read-only; the description adds genuinely useful behavior — the handoff is consumed exactly once (single-use), the session is re-inspected rather than trusted, and resumption is gated on challenge clearance. It does not say what happens when the challenge is still present (error vs no-op).

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 critical constraint ('only after the current challenge is clear') placed at the end where it lands. No filler, though the triple-verb construction packs a lot into one line.

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 non-read-only tool with no output schema, the description covers the happy path but omits failure behavior (what is returned or thrown if the challenge is unresolved or the handoff was already consumed). That gap matters for an agent deciding whether to call it or retry.

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 schema already documents task_id, handoff_id, and session_id fully. The description adds only the notion that the handoff is 'task-scoped' and matched, which is marginal beyond the schema. Baseline 3 applies when the schema carries the load.

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 chain (consume, re-inspect, resume) against concrete resources (task-scoped handoff, existing browser session). It is clearly distinguishable from captcha_handoff/inspect/wait, though it does not explicitly name which sibling it supersedes.

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 'resume only after the current challenge is clear' gives a real precondition for use, which is more than nothing. However, it never names alternatives (e.g., captcha_wait vs captcha_complete) or states when NOT to call it, so an 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?

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.