Skip to main content
Glama
Conorirish

obscura-capsolver-tool

by Conorirish

How to Add a CAPTCHA Solver Tool Alongside Obscura MCP

How to Add a CAPTCHA Solver Tool Alongside Obscura MCP

English · 简体中文 · 日本語 · Español · Português · 한국어

Introduction

When an authorized AI-agent browser task reaches a CAPTCHA checkpoint, an operator needs a controlled decision instead of an open-ended retry loop. This repository shows how an MCP client can run Obscura for the stateful browser session and use CapSolver through a separate, bounded checkpoint tool.

Obscura exposes browser tools through MCP, but it does not advertise a third-party tool plugin interface. This example therefore runs as an independent companion MCP server configured alongside Obscura. It does not modify the browser engine or claim a native integration.

Related MCP server: 2CaptchaMCP

Features

  • accepts structured state from the current Obscura browser_snapshot result;

  • requires explicit authorization and a matching snapshot origin;

  • supports one attempt with a configurable timeout capped at 120 seconds;

  • validates a ready solver result before returning a token;

  • returns a structured manual_review state for every unsafe or ambiguous branch;

  • uses fixtures only in tests and makes no real browser or solver request.

How It Works

  1. The agent uses Obscura MCP tools to navigate and inspect an authorized target.

  2. A supported verification checkpoint is detected.

  3. The agent passes the browser session ID, snapshot URL, origin, purpose authorization, and challenge type to this companion tool.

  4. Policy checks run before any solver transport is allowed.

  5. One bounded attempt may run; malformed, denied, exhausted, or timed-out work stops for a person.

Architecture

MCP-capable agent
 ├─ Obscura MCP → stateful browser_* tools
 └─ this MCP server → authorization → bounded solver transport → validated status

The two servers share only structured task context supplied by the agent. This repository does not read browser cookies, profiles, or saved credentials.

Quick Start

python -m venv .venv
source .venv/bin/activate
pip install -e .
python -m unittest discover -s tests -v
python scripts/smoke.py

Add both servers to an MCP-capable client using examples/mcp-client-config.json. Start the companion directly with:

python -m obscura_capsolver_tool.mcp_server

Usage

Call browser_snapshot first, then send one authorized checkpoint:

{
  "task_id": "authorized-qa-42",
  "origin": "https://example.test",
  "snapshot_url": "https://example.test",
  "browser_session_id": "obscura-local-1",
  "challenge_type": "recaptcha_v2",
  "authorized": true,
  "attempt": 0,
  "timeout_seconds": 45
}

The offline fixture returns either solved or manual_review. Production transport code should follow the official CapSolver API overview, task creation contract, and task result contract.

Example Output

{
  "status": "solved",
  "task_id": "authorized-qa-42",
  "browser_session_id": "obscura-local-1",
  "attempts_used": 1,
  "token": "fixture-token"
}

Project Structure

src/obscura_capsolver_tool/  policy, handler, and stdio MCP server
examples/                    dual-server MCP client configuration
tests/                       offline policy and protocol tests
scripts/                     smoke test
docs/                        five translated guides

Testing

The suite covers authorization denial, attempt exhaustion, invalid results, session/origin binding, MCP tool discovery, and the successful fixture path. It does not run Obscura or make a real CapSolver API request.

Responsible Use

Use this example only with public data, systems you own, or targets where you have explicit permission. Respect site terms, rate limits, privacy requirements, and retention policies. Do not use it for bulk account creation, access controls, private data, credential collection, or avoiding platform safeguards. Stop for human review whenever authorization, target ownership, challenge state, or result validity is unclear.

Security

Never commit API keys, session state, cookies, tokens, or captured private content. See SECURITY.md for reporting guidance.

Conclusion

This companion pattern keeps Obscura browser control separate from solver policy while preserving authorization, session binding, attempt budgets, validation, and human stopping. Replace the fixture transport only after reviewing the current official CapSolver integration guidance.

Maintainer Note

Developer sharing CapSolver integration examples.

License

MIT. See LICENSE.

Available Tools

1 tool
solve_verification_checkpointC

Handle one explicitly authorized CAPTCHA checkpoint for the current Obscura browser session.

ParametersJSON Schema
NameRequiredDescriptionDefault
originYes
attemptNo
task_idYes
authorizedYes
snapshot_urlYes
challenge_typeYes
timeout_secondsNo
browser_session_idYes

TDQS

C2.1/5.0
Behavior2/5

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

With no annotations, the description carries the burden of explaining side effects, but it only says 'Handle one explicitly authorized CAPTCHA checkpoint.' It does not disclose whether the tool submits a solution, mutates session state, waits for user interaction, or has side effects on the browser session.

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

Conciseness3/5

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

The description is a single concise sentence with no fluff, but it is too terse to be well-structured for an 8-parameter tool. It front-loads the purpose but omits necessary detail, so brevity comes at the cost of completeness.

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

Completeness1/5

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

There is no output schema, no parameter descriptions, and no context about what 'handle' entails, what outcomes are expected, or how the CAPTCHA interacts with the Obscura session. The description is not sufficient for an agent to invoke the tool correctly.

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

Parameters1/5

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

Schema description coverage is 0% and the description provides no explanation of any of the eight parameters. Parameters like challenge_type, attempt, timeout_seconds, and authorized are entirely unexplained, leaving the agent unable to infer required values or relationships.

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

Purpose3/5

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

The description states a clear resource ('CAPTCHA checkpoint for the current Obscura browser session') and an action ('Handle'), but 'Handle' is vague and does not specify whether the tool solves, dismisses, or bypasses the checkpoint. It does not need sibling differentiation because no siblings are listed, but the verb lacks precision.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, and no mention of prerequisites beyond 'explicitly authorized.' The description implies authorization is required but does not explain when the tool should be invoked or what conditions make it appropriate.

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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedsolve_verification_checkpoint

TDQS

C2.5/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly defined as solving a CAPTCHA checkpoint.

Naming Consistency5/5

With a single tool, there is no naming convention to compare against. The name 'solve_verification_checkpoint' is descriptive and follows a clear verb_noun pattern.

Tool Count2/5

A single tool for a CAPTCHA-solving server feels thin. Typical CAPTCHA services might include tools for checking status, listing pending checkpoints, or retrieving results, making this count inadequate for the apparent scope.

Completeness2/5

The tool surface only covers one action (solving a checkpoint) with no supporting operations like status checks or session management. This leaves notable gaps that could cause agent failures if the CAPTCHA flow requires more than a single solve action.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    D
    maintenance
    Enables LLM-powered browser automation and security testing with features like browser management, network monitoring, DOM manipulation, and captcha handling.
    52
    1
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables scraping and fetching websites with protection handling like Cloudflare and captchas, via an MCP interface.
    3
    1
    Apache 2.0

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Conorirish/obscura-capsolver-tool'

If you have feedback or need assistance with the MCP directory API, please join our Discord server