Resolve um captcha de imagem (texto distorcido). Envie a imagem em base64; retorna o texto reconhecido. Cobrado em créditos por solve.
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | ||
| body_base64 | Yes | ||
| case_sensitive | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations carry no behavioral hints, the description carries the burden. It successfully discloses a key behavioral trait: the operation is charged in credits per solve. It also clarifies that the image is sent as base64 and returns text. It could still mention failure modes or whether the call is synchronous, but adding the cost notice is valuable beyond the schema.
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 concise sentences deliver the essential meaning: what the tool does, what input to provide, what the output is, and the cost implication. No wasted words, and the key 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?
For a straightforward solve tool, the description gives the main flow and return value, and adds the cost detail. However, with no output schema, no parameter descriptions, and two undocumented optional parameters, it is not fully complete — especially since the sibling captcha_get_result hints at possible asynchronous behaviors that are not addressed.
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 schema has 0% description coverage, so the description must compensate. It only documents body_base64, while the optional module and case_sensitive parameters remain unexplained. This leaves important semantics about how case sensitivity and the module option work without any 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?
The description uses a specific verb ('Resolve um captcha de imagem'), specifies the resource (image/text captcha), and clearly states the output (recognized text). It distinguishes this tool from the sibling recaptcha/hcaptcha/turnstile solvers by limiting scope to generic image captchas.
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 input flow is clear — send a base64 image and get text — so usage is inferable. However, the description does not explicitly say when to prefer this tool over siblings like captcha_solve_hcaptcha or captcha_get_result, nor does it provide any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The captcha_solve_* tools are clearly distinct by captcha type, and captcha_get_result is separate. However, authenticate, connect, and toolkit_info overlap in purpose (auth/status), and marketplace bundles a huge range of unrelated functionality, creating ambiguity about which tool to use for platform management.
The captcha tools follow a consistent captcha_solve_<type> pattern, but the rest of the set uses bare verbs (connect, authenticate, marketplace) or inconsistent forms (toolkit_info, show_version). Mixing prefixed captcha tools with generic platform tools makes the naming scheme disjointed.
At 12 tools the raw count is reasonable, but the server is named 'Captcha Solver' yet includes a large platform/marketplace tool and several generic management tools. The captcha-specific scope is small (7 tools), while the extra tools feel bolted on and dilute the server's purpose.
The captcha solving surface covers main types (image, hCaptcha, reCAPTCHA v2/v3, Turnstile) plus result retrieval, which is decent. However, there is no dedicated balance/credit check or captcha task listing, and the broad marketplace/toolkit functionality makes it unclear what domains the server is supposed to fully cover.