NoneCap

Name: NoneCap
Author: nonecap

by nonecap

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Submit a captcha, get back a token. The client handles the polling, the timeouts, and the error cases so you do not have to write the fetch loop yourself.

Install

npm install nonecap

Works on Node 18+, Bun, Deno, and edge runtimes. No dependencies.

Related MCP server: 2Captcha MCP

Quick start

Grab an API key from dashboard.nonecap.com, then:

import { NoneCap } from "nonecap";

const nc = new NoneCap({ apiKey: process.env.NONECAP_KEY! });

const solve = await nc.solve({
  type: "hcaptcha",
  sitekey: "10000000-ffff-ffff-ffff-000000000001",
  url: "https://example.com/login",
});

console.log(solve.token); // the hCaptcha token, ready to submit
console.log(solve.resp_key); // hcaptcha.getRespKey() equivalent, for sites that verify the pair
console.log(solve.user_agent); // submit the token with this User-Agent: some sites check the browser version
console.log(solve.warnings); // e.g. proxy_session_refused: tokens you reported through this proxy session or its exit IP were refused; a different exit IP is more likely to pass (or, when your proxy changed its exit IP during the solve, use a sticky session per solve)

solve() submits the captcha and waits until it is done, using the API's long-poll so you are not hammering it with requests. It returns the solved solve, or throws if the solve fails or your timeout runs out.

MCP server (Claude Code, Cursor, and other MCP clients)

The package also ships nonecap-mcp, a stdio MCP server, so an AI agent can solve hCaptcha through your NoneCap account.

Claude Code:

claude mcp add nonecap --env NONECAP_API_KEY=<your key> -- npx -y -p nonecap@latest nonecap-mcp

Cursor (~/.cursor/mcp.json), Claude Desktop (claude_desktop_config.json), and most other clients take the same JSON:

{
  "mcpServers": {
    "nonecap": {
      "command": "npx",
      "args": ["-y", "-p", "nonecap@latest", "nonecap-mcp"],
      "env": { "NONECAP_API_KEY": "<your key>" }
    }
  }
}

Tools:

Tool	What it does
`solve_hcaptcha`	Solve an hCaptcha (`sitekey`, `url`; optional `type`, `rqdata`, `user_agent`, `proxy`, `wait_seconds`) and return the solve with its `token`. If the solve is still running after `wait_seconds` (default 45, at most 50, inside the 60 s that clients built on the official MCP SDK allow by default), it returns the solve id and status so the agent polls `get_solve` instead of solving again.
`get_solve`	Get a solve by id, optionally waiting up to 50 seconds for it to finish.
`cancel_solve`	Cancel a pending or running solve.
`list_solves`	List your recent solves.
`get_account`	Your credit balance and your plan's solves left today.
`report_solve_outcome`	Tell NoneCap whether the site accepted a token.

A failed call comes back as a tool error whose JSON carries the API's error code (insufficient_credits, sitekey_rate_limited, a failed solve's proxy_error, …), plus retry_after when the API sent one. Set NONECAP_BASE_URL to point the server at a different API host.

Handling failures

Every error this library throws extends NoneCapError, so you can catch the whole family or pick out the one you care about.

import {
  NoneCap,
  SolveFailedError,
  InsufficientCreditsError,
  RateLimitError,
} from "nonecap";

try {
  const { token } = await nc.solve({ type: "hcaptcha", sitekey, url });
  // use token
} catch (err) {
  if (err instanceof SolveFailedError) {
    // The message says what happened, what to do, and that nothing was charged.
    console.error(err.solve.error?.message);
    if (err.retryable) scheduleRetry();
  } else if (err instanceof InsufficientCreditsError) {
    console.error("Out of credits. Top up at dashboard.nonecap.com");
  } else if (err instanceof RateLimitError) {
    await new Promise((r) => setTimeout(r, (err.retryAfter ?? 1) * 1000));
  } else {
    throw err;
  }
}

The error subclasses are AuthenticationError (401), PermissionError (403), InsufficientCreditsError (402, with KeyCreditLimitError when one API key hit its own cap), ValidationError (422/400, with a param naming the bad field; PayloadTooLargeError for 413 and UnsupportedMediaTypeError for 415), NotFoundError (404), ConflictError (409), RateLimitError (429, with ConcurrencyLimitError, SitekeyRateLimitedError, ProxyUnavailableError (your own proxy is refusing connections) and RateCappedError (your account reached its submit rate cap on this sitekey, or your own-proxy sessions for it are at their limit) telling them apart; retryAfter is the seconds the API asked you to wait), RecognitionFailedError (422 from recognize() when no answer came back, nothing charged), APIError (5xx, with ServiceUnavailableError for a maintenance pause), and ConnectionError (the request never landed). Every error from a response carries requestId, the id to quote to support.

SolveFailedError carries the full solve. solve.error.code is a SolveErrorCode, solve.error.reason a typed sub-reason or null (proxy_rejected, sitekey_rate_limited, …), and solve.error.retryable says whether resubmitting the same request unchanged can succeed; err.retryable, err.reason and err.solveCode are shortcuts to those fields. Failed solves are never charged.

Cancelling a solve

solve() is the simple path when you just want a token. When you need to cancel while the solve is in flight — clean shutdown, freeing a worker slot, or stopping early — start it instead. solves.start() returns as soon as the submission is accepted, handing you a SolveHandle whose id is available right away.

Wait for the result when you want the token:

const handle = await nc.solves.start({ type: "hcaptcha", sitekey, url });
console.log(handle.id); // available immediately

const solve = await handle.result({ timeout: 120_000 });
console.log(solve.token);

Or hold onto the handle and cancel it from somewhere else — a shutdown hook, a request that was abandoned, a "stop" button:

const handle = await nc.solves.start({ type: "hcaptcha", sitekey, url });

process.on("SIGTERM", () => {
  handle.cancel().catch(() => {}); // free the worker slot on shutdown
});

// elsewhere, whoever needs the token still awaits it:
const solve = await handle.result();

handle.result() long-polls until the solve finishes, throwing SolveFailedError or TimeoutError exactly like solve(). The terminal outcome is memoized: once the solve actually finishes, every later result() call returns that same result. A TimeoutError is not memoized — it just means that wait gave up, so you can call result() again (for example with a larger timeout) to resume polling. Concurrent result() calls share a single in-flight poll.

handle.cancel() cancels a pending or in-flight solve. If the solve already finished, the API would answer 409; the handle swallows that and returns the solve's current state instead, since cancelling a finished solve is not something you need to handle. Cancelling settles the handle, so a concurrent or later result() stops polling and reflects the cancelled (terminal) state.

Cancelled and abandoned solves are never charged — nothing is billed unless a solve actually succeeds, and unfinished solves simply expire uncharged at the server deadline. So cancel is for cleanup and early-stop, not cost protection.

Cleaning up after a `solve()` timeout

solve() blocks until the solve settles, so it hands you no handle to cancel a solve while it's still running — for that, use solves.start() above. The one thing the solve() path offers is cleanup after a timeout: when solve() throws TimeoutError, the error usually carries the in-flight solveId (and last-known solve), so you can cancel the solve the wait gave up on. Guard on solveId being present — if the very first submission times out at the transport level, no id has been assigned yet, so solveId is undefined.

import { TimeoutError } from "nonecap";

try {
  await nc.solve({ type: "hcaptcha", sitekey, url });
} catch (err) {
  if (err instanceof TimeoutError && err.solveId) {
    await nc.solves.cancel(err.solveId);
  } else {
    throw err;
  }
}

Enterprise captchas

For hcaptcha_enterprise, rqdata is optional: many enterprise sites never issue one. When the page does pass an rqdata blob to its widget, send it, fresh for each challenge.

const { token } = await nc.solve({
  type: "hcaptcha_enterprise",
  sitekey,
  url,
  rqdata: "...", // only when the site provides one
});

Proxies

Pass a proxy as a structured object or a URL string. Solves run through it, and the bytes are metered back on the solve.

await nc.solve({
  type: "hcaptcha",
  sitekey,
  url,
  proxy: { scheme: "http", host: "1.2.3.4", port: 8080, username: "u", password: "p" },
  // or: proxy: "http://u:p@1.2.3.4:8080"
  // scheme can be http, https, socks5, socks5h, or socks4 (default http)
  // e.g. proxy: "socks5://u:p@1.2.3.4:1080"
});

Reporting token acceptance

A token that hCaptcha blessed can still be refused by the site you send it to. Tell us what happened and we tune minting against your real acceptance rate — it's free, and it's the fastest way to get a regression on your sitekey noticed.

Keep the solve_id next to the token you submit downstream, then report the verdict:

const solve = await nc.solve({ type: "hcaptcha", sitekey, url });
const ok = await submitToTheSiteYouAreAutomating(solve.token);

await nc.feedback.report({
  solve_id: solve.id,
  outcome: ok ? "accepted" : "rejected",
  reason: ok ? undefined : "session invalidated", // optional, the code your target returned
  context: ok ? undefined : "3rd retry, rotating residential pool", // optional, anything you think would help us diagnose it
});

At volume, buffer the verdicts and flush them in one call. Reports over 500 are split across requests for you:

const batch = await nc.feedback.reportMany([
  { solve_id: "solve_01J...", outcome: "accepted" },
  { solve_id: "solve_01J...", outcome: "rejected", reason: "...", context: "..." },
]);

// Items resolve independently, so the call succeeds even when some are
// rejected — check `failed` rather than relying on a throw.
if (batch.failed > 0) {
  console.warn(batch.results.filter((r) => r.status === "error"));
}

outcome is one of accepted, rejected, unknown (submitted, verdict unclear), unused (never submitted), or error (downstream broke for a non-token reason). Only accepted and rejected count toward the acceptance rate.

reason and context are both optional free text. reason is the code or message your target gave you; context is anything else about the attempt you think would help us diagnose it, with no schema at all. Neither is parsed — they are what a human reads when you raise a ticket, and they carry the half of a rejection we cannot see from our side.

Reporting the same solve again corrects the earlier verdict, so retries and late fixes are safe. You can report any of your own solved solves within ~30 days of the solve; corrections to something you already reported are never cut off by that window.

Recognizing images

If you run your own browser and only need the answer to a challenge, send the instruction and images to recognize(). The answer comes back in the same response: no token, no polling.

const { id, data } = await nc.recognize({
  type: "hcaptcha",
  task: "Please click each image containing a bus",
  image_data: tiles, // base64 or data: URIs, 1-27 tiles; or image_urls with hCaptcha image URLs
});
// data: boolean[], one per tile, in the order you sent them

For a click-the-point challenge send exactly one image with type: "hcaptcha_area_select". data is the first point as { x, y, w: 0, h: 0 } and points lists every point to click, all in percent of the image.

You can also send the challenge as hCaptcha served it, in NopeCHA's v1 recognition shape:

const result = await nc.recognize({
  data: {
    request_type: "image_drag_drop", // or image_label_binary, image_label_area_select
    requester_question: { en: "Drag the piece into place" },
    tasklist: [{ task_key, datapoint_uri, entities }],
  },
});

image_label_binary answers pages of 9 booleans (boolean[][]), image_label_area_select one box per task (null when there is no point) plus points per task, and image_drag_drop the drop box for each entity per task. The return type follows the request, so TypeScript knows which one you got.

When no answer comes back the call throws RecognitionFailedError and nothing is charged. An answered call's charge is final. You can tell us whether the answer worked on the challenge, which helps us track accuracy; it is optional, free, and does not refund the call:

await nc.reportRecognitionOutcome(id, solved ? "solved" : "failed");

The first report for an id sticks; a repeat returns it unchanged. Calls are capped per API key by your account's concurrency limit, so a burst over it gets ConcurrencyLimitError or RateLimitError with retryAfter set.

Lower-level API

solve() is the convenient path. When you want control over submission and polling, the raw resource methods map one to one to the REST API.

// Submit without waiting: returns immediately with a pending solve
const pending = await nc.solves.create({ type: "hcaptcha", sitekey, url });

// Submit and hold the connection up to 30s for it to finish
const maybeDone = await nc.solves.create({ type: "hcaptcha", sitekey, url }, { wait: 30 });

// Poll one solve, long-polling up to 30s
const solve = await nc.solves.retrieve(pending.id, { wait: 30 });

// Cancel a pending or in-flight solve
await nc.solves.cancel(pending.id);

// List a page of solves
const page = await nc.solves.list({ limit: 50, status: "solved" });

// Or iterate every solve, newest first
for await (const s of nc.solves.listAll()) {
  console.log(s.id, s.status);
}

// Your account and credit balance
const me = await nc.me();
console.log(me.credits_balance);
// With a plan: what is left of today's solves, and when they reset (00:00 UTC).
console.log(me.plan?.remaining_today, me.plan?.resets_at);

Cancelling and timeouts

Pass an AbortSignal to cancel any call, and a timeout to bound how long solve() waits.

const ac = new AbortController();
setTimeout(() => ac.abort(), 60_000);

await nc.solve(
  { type: "hcaptcha", sitekey, url },
  { timeout: 120_000, signal: ac.signal },
);

Configuration

new NoneCap({
  apiKey: "nc_live_...",        // required
  baseURL: "https://api.nonecap.com", // override if you need to
  timeout: 100_000,             // per HTTP request, ms
  fetch: customFetch,           // inject your own fetch
});

License

MIT, see LICENSE.

Available Tools

6 tools

cancel_solveCancel a solveA

DestructiveIdempotent

Cancel a pending or running solve. Cancelled solves are not charged.

Name	Required	Description	Default
`id`	Yes	The solve id (solve_…).

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is covered. The description adds genuine context beyond them: the billing consequence ('Cancelled solves are not charged') and the set of cancellable states.

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

Conciseness5/5

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

Two short sentences, zero filler, with the cancellable-state scope front-loaded before the billing note.

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

Completeness4/5

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

For a single-parameter mutation with full annotation coverage, the description supplies the essentials: scope of valid targets and cost implications. Only the outcome of cancelling a non-cancellable solve is left unstated.

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

Parameters3/5

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

Only one parameter, and the schema documents it fully (100% coverage) including the 'solve_…' format. The description adds nothing about the id beyond what the schema states, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb ('Cancel') and resource ('solve') with a scoping qualifier ('pending or running'). This distinguishes it from read-oriented siblings like get_solve and list_solves, though it doesn't name them explicitly.

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

Usage Guidelines3/5

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

The phrase 'pending or running' implies the applicability condition, but the description never states what happens if the solve is already completed/failed, nor does it point to an alternative (e.g., report_solve_outcome) for such cases.

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

get_accountGet accountA

Read-only

Get your NoneCap account: credit balance, and your plan's solves left today.

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that, the description discloses the returned data (credit balance and today's remaining solves), which is meaningful behavioral context, and the phrase "left today" hints at a daily-resetting quota. It stops short of stating whether the quota resets on a fixed schedule or requires authentication details.

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

Conciseness5/5

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

A single front-loaded sentence with no filler, listing the two payoff fields immediately. 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.

Completeness4/5

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 summarizes the returned fields, which is what an agent most needs here. Minor gaps remain — no mention of plan name, currency, or quota reset timing — but for a simple read-only lookup this is close to sufficient.

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

Parameters4/5

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

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a no-argument call scoped to the calling account.

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

Purpose4/5

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

States a specific verb and resource (get account) and enumerates what it returns: credit balance and remaining solves for today. This clearly separates it from siblings like solve_hcaptcha, cancel_solve and list_solves, which operate on individual solves. The odd string "NoneCap" reads like an unfilled placeholder and slightly muddies the name of the service.

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

Usage Guidelines3/5

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

Usage is implied: call it to check credits or how many solves remain today. There is no explicit when-to-use/when-not guidance and no mention of alternatives, though for a zero-parameter account lookup the implied usage is fairly unambiguous.

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

get_solveGet a solveA

Read-only

Get a solve by id: its status, and the token once it is solved. Set wait_seconds to wait for it to finish.

Name	Required	Description	Default
`id`	Yes	The solve id (solve_…).
`wait_seconds`	No	Hold up to this many seconds (1-50) for the solve to finish. Omit to return at once.

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description usefully discloses that the token only materializes once the solve is solved and that wait_seconds holds the call open, which is real behavioral context. It says nothing about what happens on failure, cancellation, or timeout.

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

Conciseness5/5

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

A single tight sentence with the return payload front-loaded and the optional parameter behavior last. No filler.

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

Completeness3/5

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

With no output schema, the description must carry the return shape, and it only sketches it as 'status, and the token'. For a polling retrieval tool, an agent still lacks the field layout and the behavior on failed/expired solves.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented including the 1-50 bound and the 'omit to return at once' default. The description restates the wait semantics and adds no syntax or edge-case detail beyond the schema; baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource (get a solve by id) and names the payload the caller gets back (status, token). It implicitly differentiates from list_solves by being id-scoped, but 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.

Usage Guidelines3/5

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

The clause 'Set wait_seconds to wait for it to finish' gives usable guidance on the long-poll mode versus the immediate-return default. There is no explicit when-not or pointer to alternatives like list_solves or cancel_solve.

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

list_solvesList solvesA

Read-only

List your recent solves, newest first.

Name	Required	Description
`type`	No	Only solves of this type.
`limit`	No	Page size, 1-100. Default 20.
`status`	No	Only solves with this status.
`starting_after`	No	A solve id: return the page after it (the last id of the previous page).

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds two genuine traits beyond that — the results are account-scoped ('your') and ordered newest first — but says nothing about pagination behaviour or result size, which matter for a list endpoint.

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

Conciseness5/5

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

A single short sentence that front-loads the verb and resource and appends the ordering constraint. Nothing is wasted and nothing essential is buried.

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

Completeness4/5

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

For a simple, fully-documented, read-only list tool with no output schema, the description plus schema covers what an agent needs to invoke it. The only gap is pagination guidance, which the schema's starting_after description largely supplies.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (type, limit, status, starting_after) are already documented in the schema, including enum meanings and paging semantics. The description adds no parameter-level detail beyond the implicit newest-first ordering, so the baseline 3 is appropriate.

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

Purpose4/5

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

States a specific verb and resource ('List your recent solves') and the sort order, which distinguishes it clearly from the sibling get_solve. It stops short of naming siblings or scope boundaries, but the read/list purpose is unambiguous.

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

Usage Guidelines3/5

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 for browsing recent solves, and the presence of 'starting_after' signals pagination, but the description never says when to use this versus get_solve or how paging works. No exclusions or alternatives are stated.

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

report_solve_outcomeReport a token's outcomeA

Idempotent

Tell NoneCap whether the site accepted a solve's token. Free; reporting the same solve again corrects it.

Name	Required	Description
`reason`	No	What the site returned when it refused the token.
`context`	No	Anything else about the attempt that would help diagnose it.
`outcome`	Yes	accepted or rejected by the site; unknown (submitted, verdict unclear); unused (never submitted); error (the site failed for a reason unrelated to the token).
`solve_id`	Yes	The id of a solved solve.

TDQS

A3.8/5.0

Behavior4/5

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

Adds context beyond the annotations: the call is free and re-reporting the same solve corrects the prior result. The correction behavior is consistent with idempotentHint=true, so there is no contradiction. It still doesn't say what effect reporting has on account state or how outcomes are consumed, keeping it below 5.

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

Conciseness5/5

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

Two short sentences with the core action front-loaded and the cost/idempotency note second. Every clause carries useful information and there is no padding.

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

Completeness4/5

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

With a fully described schema, annotations covering safety and idempotency, and no output schema, the description supplies the important extras (free, correction semantics). It is slightly incomplete on when-triggered usage and what happens after reporting, but nothing essential to invoking it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100% and the enum values are fully documented in the schema, so the description does not need to explain parameters. It adds nothing about the reason/context fields, so it meets only the baseline.

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

Purpose4/5

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

States a specific verb and resource ("Tell NoneCap whether the site accepted a solve's token"), which clearly identifies a reporting/mutation operation distinct from the read/list/create siblings. It does not name a sibling to contrast with, but the purpose is unambiguous.

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

Usage Guidelines3/5

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

Use is implied (after a solve, report its outcome) and the description notes idempotent correction behavior, but it never states when to use this versus get_solve/list_solves or any prerequisites (e.g., must the solve be completed first). No exclusions are given.

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

solve_hcaptchaSolve an hCaptchaA

Solve an hCaptcha and return the token. Waits up to wait_seconds; if the solve is still running then, returns its id and status: call get_solve with the id rather than solving again. Only successful solves are charged.

Name	Required	Description
`url`	Yes	The URL of the page the captcha is on.
`type`	No	hcaptcha (default) or hcaptcha_enterprise.
`proxy`	No	Proxy to solve through, as a URL: scheme://user:pass@host:port (http, https, socks5, socks5h or socks4).
`rqdata`	No	Enterprise only: the rqdata the site passes to its widget, if it passes one.
`sitekey`	Yes	The hCaptcha sitekey on the page.
`user_agent`	No	The user agent of the browser that loaded the page, as is. Leave out if you do not have it.
`wait_seconds`	No	Seconds to wait for the result, 0-50. Default 45. 0 returns right after submitting.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly=false and openWorld=true, but the description adds information annotations can't carry: the timeout semantics of wait_seconds, the partial-result shape (id + status), and the billing rule that only successful solves are charged. The billing disclosure is a materially important behavioral trait for an agent deciding whether to retry.

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

Conciseness5/5

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

Three sentences, no filler, and the core contract (returns token, or id+status after waiting) is front-loaded ahead of the fallback instruction and the billing note. Every sentence earns its place.

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

Completeness4/5

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

With 7 params, no output schema, and sparse annotations, the description does a good job of describing both return shapes and the charging rule. It stops short of describing failure behavior — what is returned or what to do when a solve errors out rather than merely running long — which matters for a non-idempotent, open-world operation.

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

Parameters3/5

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

Schema description coverage is 100%, including the wait_seconds 0-50 range, default 45, enum for type, and the proxy URL format. The description only restates wait_seconds, adding no meaning beyond the schema. Baseline 3 is correct when the schema does all the work.

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

Purpose5/5

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

States a specific verb and resource ("Solve an hCaptcha and return the token") and immediately distinguishes the async path by naming the sibling get_solve. An agent can tell what this does and which sibling handles the follow-up 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.

Usage Guidelines4/5

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

Gives an explicit conditional rule: if the solve is still running after wait_seconds, call get_solve with the id rather than solving again. That is a real when-to-use/when-not instruction. It doesn't cover the other siblings (cancel_solve, report_solve_outcome), so not a full 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.13.0Nov 1, 2026
- First observedcancel_solve
- First observedget_account
- First observedget_solve
- First observedlist_solves
- First observedreport_solve_outcome
- First observedsolve_hcaptcha

Deploy Server

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A4/5.0

Scored 2026-11-01 21:55 across 6 tools

Disambiguation5/5

Each tool maps to a distinct action in the solve lifecycle: start (solve_hcaptcha), poll by id (get_solve), cancel (cancel_solve), list (list_solves), outcome reporting (report_solve_outcome), and account lookup (get_account). The descriptions explicitly resolve the one potential overlap between solve_hcaptcha and get_solve (both can wait) by instructing callers to poll with get_solve rather than re-solving.

Naming Consistency4/5

Names follow a verb_noun shape (solve_hcaptcha, cancel_solve, list_solves, get_account, report_solve_outcome, get_solve). The only wrinkle is that 'solve' is a verb in solve_hcaptcha but a noun object in cancel_solve/get_solve/report_solve_outcome, a minor inconsistency that remains readable.

Tool Count5/5

Six tools is well-scoped for a captcha-solving service: one per lifecycle operation plus account info. No tool feels redundant or missing from the set.

Completeness5/5

The surface covers the full solve lifecycle: initiate, poll/retrieve token, cancel, list history, report acceptance, and check credits/quota. There are no obvious dead ends for an agent driving a solve end-to-end.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Related MCP Connectors

Captcha Solver B
io.github.mcp-dir
Solve reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and image captchas. Platform-hosted, no creden
Browser Automation Web Scraping
121
https://api.mcp.ai/p_captcha
Solvecha A
com.solvecha
Solve reCAPTCHA image grids, text captchas, GeeTest and FunCAPTCHA for AI agents. Free tier.
Browser Automation Web Scraping Penetration Testing
61
https://api.solvecha.com/mcp
cloudflare-solver B
com.jojapi
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
Web Scraping Browser Automation
11
https://mcp.jojapi.com/cloudflare-solver
SiliconBridge
io.github.aataqi-boop
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Autonomous Agents Customer Support Security
2
https://siliconbridge.xyz/mcp

Related MCP Servers

2CaptchaMCP
Security Browser Automation Web Scraping
EricFor
F
license
Not graded
quality
D
maintenance
Integrates with 2Captcha to solve various CAPTCHA types (image, reCAPTCHA, hCaptcha, etc.) for AI agents via MCP.
Updated 8 months ago (2026-03-04 02:08 UTC)
121 npm
-
2Captcha MCP
Web Scraping Browser Automation
0-SOFT
A
license
Not graded
quality
C
maintenance
MCP server that exposes the full 2Captcha API surface to Claude Code, enabling solving of 31 captcha types, management tools, and webhook integration for asynchronous solves.
Updated 3 months ago (2026-07-20 06:12 UTC)
5
MIT
captcha-solver-tool
walking-tamas
F
license
Not graded
quality
C
maintenance
Enables solving CAPTCHAs in MCP workflows with authorization, bounded attempts, and structured result validation.
Updated 2 months ago (2026-09-08 07:17 UTC)
-
Captcha Solver
Browser Automation Web Scraping Autonomous Agents
mcp-dir
A
license
Not graded
quality
C
maintenance
Enables solving reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile, and image captchas through MCP tools. Users pay per solve with prepaid credit and can retrieve results asynchronously.
Updated 2 months ago (2026-08-30 19:43 UTC)
MIT

Install

Quick start

MCP server (Claude Code, Cursor, and other MCP clients)

Handling failures

Cancelling a solve

Cleaning up after a solve() timeout

Enterprise captchas

Proxies

Reporting token acceptance

Recognizing images

Lower-level API

Cancelling and timeouts

Configuration

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cleaning up after a `solve()` timeout