ruflo-captcha-solver-mcp-tool
So fügen Sie ein CAPTCHA-Löser-Tool zu Ruflo hinzu
Ein ausführbares, fixture-first stdio-MCP-Begleittool mit einem Wiederherstellungsversuch, begrenztem Polling, strukturierter Validierung und menschlicher Übergabe.
English · 简体中文 · 日本語 · Español · Português · 한국어
Einführung
Wenn ein autorisierter Ruflo-Workflow auf eine CAPTCHA-Unterbrechung stößt, benötigt er ein begrenztes Wiederherstellungstool, das entweder ein validiertes Ergebnis zurückgibt oder für eine menschliche Überprüfung anhält. Dieser begleitende MCP-Server zeigt, wie eine Ruflo-Aufgabe CapSolver nur nach expliziter Autorisierung und einem unterstützten Challenge-Signal aufrufen kann. Er modifiziert Ruflo nicht und beansprucht keine offizielle Partnerschaft. Das API-Aufgabenobjekt bleibt vom Aufrufer überprüft, sodass das Beispiel keine Produktfelder erfindet.
Related MCP server: M365 Copilot Web Bridge
Funktionen
Ein MCP-Tool:
captcha_solver_recover_onceExplizite Autorisierungs- und Challenge-Gates
Stabile Wiederherstellungs-ID für Idempotenz
Ein Create-Aufruf und höchstens fünf Ergebnisabfragen
Timeouts, strukturierte Fehler und menschliche Übergabe
Offline-Fixtures; kein echter Schlüssel oder Ziel erforderlich
So funktioniert es
Ruflo leitet eine genehmigte Aufgabe an den lokalen stdio-Server weiter. Das Tool validiert Autorisierung, Challenge-Zustand, Kontext und Budget, bevor es den offiziellen Auftragserstellungsvertrag verwendet. Es akzeptiert nur eine fertige Lösung, andernfalls pollt es innerhalb des konfigurierten Budgets und stoppt sicher.
Architektur
Ruflo → MCP tools/call → policy gates → CapSolver client → result validator → resume or human handoff
Schnellstart
npm test
npm run smoke
CAPSOLVER_API_KEY=replace_me npm startÖffnen Sie in der Web-UI von Ruflo MCP (n) → Add Server, wählen Sie einen stdio-Server und verwenden Sie node src/server.js als lokalen Befehl. Ruflo dokumentiert auch HTTP- und SSE-Endpunkte; dieses Repository implementiert absichtlich nur stdio.
Verwendung
Verwenden Sie examples/tool-call.json als Fixture-Form. Ersetzen Sie task nur mit einem Aufgabenobjekt, das gegen den offiziellen createTask-Anfragevertrag geprüft wurde. Die Ergebnisabfrage folgt dem offiziellen getTaskResult-Lebenszyklus.
Beispielausgabe
{"ok":true,"status":"ready","recoveryId":"qa-run-0001","polls":1,"solution":{"fixtureResult":"ok"}}Unterstützte Szenarien
Eigene Test-Fixtures, explizit autorisierte QA und verhältnismäßige Automatisierung gegen genehmigte Ziele. Nicht unterstützte Zustände stoppen für eine menschliche Überprüfung.
Projektstruktur
src/server.js— stdio-JSON-RPC-Routersrc/tool.js— MCP-Tooldefinition und sichere Fehlerzuordnungsrc/recovery.js— begrenzter Wiederherstellungsvertragtests/— Offline-Unit-Testsexamples/— Nur-Fixture-Toolaufruf
Testen
npm test
npm run smokeDie Tests verwenden injizierte Clients und rufen niemals eine Live-API auf.
Fehlerbehebung
AUTHORIZATION_REQUIRED, NO_SUPPORTED_CHALLENGE, DUPLICATE_RECOVERY, TIMEOUT und BUDGET_EXHAUSTED sind Stoppsignale. Überprüfen Sie die Aufgabe und übergeben Sie sie einem Menschen, anstatt endlos zu wiederholen.
Verantwortungsvolle Nutzung
Verwenden Sie nur öffentliche Daten, eigene Systeme oder Ziele, die durch eine ausdrückliche schriftliche Genehmigung abgedeckt sind. Respektieren Sie Zugriffsrichtlinien, Bedingungen, Ratenlimits, Aufbewahrungslimits und menschliche Stoppentscheidungen. Verwenden Sie dieses Beispiel nicht für private Daten, Anmeldeinformationen, sensible persönliche Informationen, uneingeschränkte Sammlung oder unbefugten Zugriff.
Mitwirken
Halten Sie Änderungen fixture-first, begrenzt und fail-closed. Führen Sie beide Prüfungen vor einem Pull-Request aus.
Sicherheit
Committen Sie niemals Schlüssel, Cookies, Browserprofile, private Ziel-URLs oder Produktionsantworten. Siehe SECURITY.md.
Fazit
Dieses Begleittool gibt Ruflo eine kleine, prüfbare Wiederherstellungsgrenze, während Routing, Budgets, Validierung und menschliche Kontrolle explizit bleiben. Bestätigen Sie für einen autorisierten Produktionsadapter jedes Aufgabenfeld anhand der CapSolver-Dokumentation, bevor Sie es verwenden.
Hinweis des Betreuers
Entwickler, der CapSolver-Integrationsbeispiele teilt.
Lizenz
MIT
Available Tools
1 toolcaptcha_solver_recover_onceC
Perform one bounded CAPTCHA recovery for an explicitly authorized Ruflo task.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| budget | No | ||
| context | Yes | ||
| authorization | Yes | ||
| challengeDetected | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It mentions 'bounded' (implying a polling limit) and 'recovery' (implying a state change), but fails to disclose side effects, failure modes, whether the operation is destructive, or what happens if authorization is insufficient. An agent is left guessing about the tool's actual impact.
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 tightly written single sentence that front-loads the action and scope. Every word earns its place, avoiding filler or redundant phrasing. It is appropriately concise for the action described, though it sacrifices explanatory depth for brevity.
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?
Given the tool's complexity (5 parameters, nested objects, no output schema, no annotations), the description is grossly insufficient. It does not explain what 'CAPTCHA recovery' entails, how the polling budget works, what constitutes a valid 'task', or what the response will be. An agent cannot reliably construct a correct invocation from this description alone.
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 0% and the description provides no parameter-level explanation. The terms 'authorization', 'challengeDetected', 'task', 'context', and 'budget' appear in the schema, but the description gives no hints about their meanings, relationships, or expected values. The agent must infer everything from the schema alone, which the description should supplement.
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 names a specific verb ('Perform') and a clear resource ('CAPTCHA recovery'), with a scope constraint ('one bounded') and a precondition ('explicitly authorized Ruflo task'). It clearly communicates the core action, though 'Ruflo' is undefined jargon that may confuse an agent outside that domain.
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 description implies it should be used only when a CAPTCHA is detected and authorization is explicit, as reflected in the schema constants. However, it gives no explicit when-not-to-use guidance, no mention of alternatives (though no siblings exist), and no context about when recovery would fail or should be retried.
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.
1 tool update
v1.0.0- First observed
captcha_solver_recover_once
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is specific (recover once) even if the underlying 'Ruflo task' is opaque.
With a single tool, naming consistency is trivially maintained. The name 'captcha_solver_recover_once' follows a clear verb_noun_adverb pattern without conflicting conventions.
A single tool is far too few for a CAPTCHA solver domain. Typical workflows require multiple operations (solve, verify, status), so this feels like a deliberately minimal or unfinished server.
The sole tool covers a narrow 'recover once' action, but lacks standard CAPTCHA operations like solving, verification, or result retrieval. The surface is severely incomplete for the stated purpose.
Maintenance
Related MCP Connectors
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Remote MCP for C2PA intake verifier MCP, structured receipts, audit logs, and reviewer-ready evidenc
A paid remote MCP for CLI tool MCP, built to return verdicts, receipts, usage logs, and audit-ready
Verified component catalog over remote MCP: agents pick component ids and get a stamped project repo that builds. Connect at https://www.botkelp.com/mcp. Auth: MCP OAuth 2.1, or a Bearer bk_live_ API key; initialize and tools/list are open.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables AI agents to manage secrets and credentials from a secure vault via MCP tools over stdio.7MIT
- AlicenseNot gradedqualityDmaintenanceExposes a user-authenticated Microsoft 365 Copilot Chat browser session as a stdio MCP server, enabling AI-powered chat interactions via MCP tools like copilot_chat and copilot_status.2MIT
- AlicenseCqualityAmaintenanceMCP stdio bridge for the Delx Protocol: continuity, witness, recovery, ontology and passport tools.10037 npmMIT
- AlicenseBqualityDmaintenanceA local, evidence-driven MCP runtime and control plane for open-source maintainers that provides workspace-bounded tools including controlled file operations, command execution, validation primitives, durable execution records, and human review workflows via stdio and Streamable HTTP transports.33MIT