Tu servidor MCP devuelve 429 cuando los agentes lo golpean. captcha-mcp hace que se ganen su siguiente llamada en su lugar. Entrega al agente un rompecabezas de prueba de trabajo (gratis, ~5s de CPU) o una factura Lightning de 3 sats — ambas son señales de retroceso legibles por máquina que un llamante autónomo puede satisfacer sin cuenta, correo electrónico o clave API.
Tres herramientas sobre stdio o HTTP. Solo stdlib. Sin registro, respaldo gratuito, autohospedado, sin reparto de ingresos.
429 Too Many Requests es la forma equivocada para la era de los agentes. Hay tres patrones que se repiten en los informes de servidores MCP:
Los frameworks de agentes tratan el 429 como un fallo de conexión. Reintentan de inmediato, a menudo con una retrocesión exponencial que sigue siendo demasiado agresiva, y amplifican la sobrecarga que provocó el límite en primer lugar.
No hay una señal por llamante. Un 429 se dispara para el bucket, no para el agente. Un llamante ruidoso consigue que todos los demás sean limitados, y el servidor no tiene forma de pedir específicamente al ruidoso que vaya más despacio.
Retry-After es informativo y con frecuencia se ignora. Los agentes no lo parsean de forma consistente, no lo respetan de forma consistente y no tienen incentivo para esperar — el coste de reintentar es cero.
captcha-mcp sustituye el 429 por un desafío estilo 402. La siguiente llamada le cuesta algo al llamante (segundos de CPU o 3 sats). Ese coste es por llamante, legible por máquina y autolimitante — un agente que no pueda resolver el rompecabezas no puede inundar el endpoint.
Related MCP server: @bitcoinbenji/mcp
npx -y @powforge/captcha-mcpSin instalación, sin configuración, sin clave API. El servidor arranca en stdio y espera a un cliente MCP.
Para conectarlo a Claude Code, Cursor o cualquier host compatible con MCP, añade a tu configuración:
{
"mcpServers": {
"powforge-captcha": {
"command": "npx",
"args": ["-y", "@powforge/captcha-mcp"]
}
}
}O ejecuta npx @powforge/captcha-mcp --install para imprimir el bloque de configuración.
Envuelve el servicio pow-captcha de PowForge (captcha.powforge.dev) como tres herramientas MCP:
Herramienta | Propósito |
| Solicita un rompecabezas de prueba de trabajo nuevo. Devuelve |
| Envía un nonce resuelto. Devuelve un token de acceso firmado con HMAC de 5 minutos. |
| Salud del servidor, estadísticas de por vida, metadatos del endpoint L402. |
El nivel gratuito le cuesta al agente ~5-10 segundos de tiempo de CPU (SHA-256, por defecto 14 bits cero iniciales). El nivel de pago cuesta 3 sats a través de Lightning mediante L402 (RFC 7235 + factura bolt11 en WWW-Authenticate).
Enfoque | Coste por llamada | Cuenta requerida | Autohospedado | Amigable para agentes |
Claves API | $0 | sí | n/a | no |
OAuth | $0 | sí | n/a | no |
Medición de Stripe | alta sobrecarga | sí | n/a | no |
Plataforma gestionada de autenticación MCP | 100–2000 sats | no | no | sí |
PoW + L402 (este) | segundos o 3 sats | no | sí | sí |
Los agentes no tienen direcciones de correo electrónico. No hacen clic en enlaces de confirmación. No introducen tarjetas de crédito. PoW + Lightning es la única primitiva de autenticación que funciona para llamantes completamente autónomos.
Las plataformas gestionadas de autenticación MCP funcionan, pero cobran 100–2000 sats por llamada en la infraestructura del proveedor — tus ingresos fluyen a través de sus raíles. Este paquete se ejecuta en tu servidor, tu nodo Lightning, tus claves. Tú te quedas los sats.
Establece CAPTCHA_URL para apuntar a un backend de captcha diferente. El valor por defecto es http://localhost:3077 para que puedas ejecutar toda la pila localmente para desarrollo. Los despliegues de producción lo apuntan a https://captcha.powforge.dev.
CAPTCHA_URL=https://captcha.powforge.dev npx @powforge/captcha-mcpLos clientes MCP alojados (Smithery, hosts basados en navegador) necesitan HTTP, no stdio. Pasa --http o establece HTTP_MODE=1:
HTTP_MODE=1 PORT=3200 npx @powforge/captcha-mcp
# or
npx @powforge/captcha-mcp --httpEl servidor entonces escucha en:
Endpoint | Método | Propósito |
| POST | Solicitud JSON-RPC única, respuesta JSON-RPC única. Las notificaciones devuelven 202. |
| GET | Flujo SSE para notificaciones empujadas por el servidor (se mantiene abierto con un latido de 25s). |
| GET | Sonda de actividad — devuelve |
Sin estado. Sin ids de sesión. CORS abierto (Access-Control-Allow-Origin: *) para que los clientes de navegador funcionen. El modo Stdio no ha cambiado y sigue siendo el predeterminado — npx @powforge/captcha-mcp sin ninguna bandera sigue hablando JSON-RPC por stdin/stdout.
Prueba de humo del transporte HTTP:
HTTP_MODE=1 PORT=3200 node src/server.js &
curl -X POST http://localhost:3200/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}'Devuelve {jsonrpc:"2.0", id:1, result:{protocolVersion:"2024-11-05", capabilities:{tools:{}}, serverInfo:{...}}}.
Clona el repositorio del widget captcha o ejecuta el servicio público. El servidor MCP solo necesita acceso HTTP a los endpoints de captcha listados en status.
git clone https://github.com/zekebuilds-lab/captcha-mcp
cd captcha-mcp
node src/server.jsImprime ready en stderr y espera JSON-RPC en stdin.
Prueba de humo del protocolo manualmente:
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' | node src/server.jsDeberías ver una respuesta JSON con serverInfo: { name: "@powforge/captcha-mcp", version: "0.2.5" }.
Cuando un agente envía un token a tu servicio, verifícalo sin confiar en el agente:
curl -X POST https://captcha.powforge.dev/api/token/verify \
-H "Content-Type: application/json" \
-d '{"token":"<token-from-verify-tool>"}'Devuelve {valid: true, method, issued_at, expires_at} o {valid: false, reason}.
@powforge/captcha — el widget de navegador para el mismo servicio.
@powforge/mcp-l402-gate — middleware de Express para proteger cualquier servidor MCP con L402 + puntuación de profundidad de identidad.
@powforge/mcp-identity — oráculo de reputación de agentes. Combínalo con esta puerta para protección contra abusos en la primera llamada.
El espacio de proteger servidores MCP se está llenando. Este es el panorama honesto, ordenado por la cercanía con la que cada herramienta se solapa con lo que hace captcha-mcp.
Herramienta | Vía de pago | Modelo de autenticación | Autohospedado | Nivel PoW gratuito | Sin cuenta para pagar |
PayGated | Créditos de Stripe | API key + OAuth 2.1 + PKCE + M2M | sí (MIT) | no | no (registro de cliente de Stripe por llamante) |
APort | no revelado | credenciales verificables W3C, hook pre-herramienta | socio de diseño | no | n/a (audita, no cobra) |
AgentSign | no revelado | pasaporte firmado con Ed25519 + puerta de confianza | desconocido | no | n/a |
x402-mcp | USDC en cadena | firma de cartera | sí | no | no (necesita cartera financiada) |
Managed MCP auth (Auth0 for AI, MintMCP) | SaaS | OAuth 2.0 / SAML / SSO | no | no | no |
captcha-mcp (este) | Lightning (L402) | Puerta PoW + salto L402 + nivel gratuito | sí | sí | sí |
PayGated es la colisión más cercana. Mismo discurso de "monetizar herramientas MCP por llamada", misma postura de autohospedado + código abierto, pero se decanta por Stripe. Eso significa que necesitas una cuenta de Stripe en buen estado (KYC, un banco, un país compatible) para cobrar, y cada llamante necesita un registro de cliente de Stripe antes de poder pagarte un céntimo. El diferenciador de captcha-mcp es la vía sin cuenta: un autor de agentes no estadounidense paga 3 sats por llamada en unos 200 ms sin KYC, o resuelve un rompecabezas PoW gratuito si no va a pagar en absoluto.
APort y AgentSign se sitúan en una capa diferente. Registran quién usó una herramienta y bajo qué autoridad; no ponen precio a la llamada. Se combinan con una puerta como esta en lugar de reemplazarla.
Ninguna de ellas pone precio al acto de interactuar. Todas las demás filas asumen que el llamante ya es una identidad autorizada y miden o auditan después. El nivel PoW aquí es el único mecanismo de la tabla que pone un coste sobre la interacción en sí, no sobre la identidad del actor. Esa es la postura que defiende este paquete.
Un desglose más extenso frente a x402-mcp, @agentauth/mcp y Cloudflare ARC/ACT está en powforge.dev/mcp/compare/x402-mcp.
MIT
Request a fresh PoW challenge from the PowForge captcha service. Returns {id, salt, difficulty, signature, instructions}. The agent must find a nonce such that SHA-256(salt + nonce) has at least difficulty leading zero bits, then call the verify tool. Free tier — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool creates a new challenge (non-idempotent), returns specific fields, requires a subsequent PoW solution, and mentions free tier. Lacks rate limit info but is adequate.
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 sentences concisely cover purpose, return structure, workflow, and free tier. No redundancies or fluff.
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?
The tool has no input schema and no output schema, so the description fully covers both: explains that no input is needed and details the returned object fields along with subsequent steps. Sufficient for a simple tool.
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?
No input parameters exist, so schema coverage is 100%. The description adds value by explaining the return structure, which is not parameter semantics but compensates for missing output 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 clearly states the verb 'Request' and resource 'fresh PoW challenge from PowForge captcha service', and distinguishes from sibling 'verify' by mentioning the complete workflow including the call to verify.
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 explains when to use (requesting a captcha challenge) and what to do next (find nonce, call verify), but does not explicitly contrast with 'status' or provide when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return PowForge captcha server health, lifetime stats (pow_solves, ln_skips, challenges_issued), and L402 endpoint metadata (scope, price_sats, paid endpoint URL). Use this to discover the Lightning skip price before paying, or as a liveness check.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and adequately lists the return data: health, lifetime stats, and L402 metadata. It implies a read-only operation but could explicitly state no side effects.
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?
The description is a single dense sentence that is front-loaded with the main purpose. It could be split into two sentences for readability, but it is efficient and contains no fluff.
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 no output schema, the description explains the return values and use cases adequately. It does not specify response format or error handling, but for a health endpoint, the provided information is sufficient for tool selection.
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 tool has zero parameters and schema coverage is 100% (vacuously). Baseline for zero parameters is 4, and the description adds value by detailing the output fields beyond the empty 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 clearly states the tool returns health, lifetime stats, and L402 endpoint metadata. It distinguishes itself from siblings 'challenge' and 'verify' by specifying use cases like discovering the Lightning skip price and liveness check.
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 explicitly provides two use cases: discovering the Lightning skip price before paying and as a liveness check. It gives clear context for when to use the tool, though it does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a PoW solution. Input: {salt, nonce, id, signature, algo?, difficulty?} from a prior challenge call plus the nonce the agent computed. Returns a 5-minute HMAC-signed token on success, or {valid: false, reason} on failure. Tokens can be re-verified server-side via POST /api/token/verify.
| Name | Required | Description | Default |
|---|---|---|---|
| salt | Yes | Hex salt from the challenge response | |
| nonce | Yes | Nonce string the agent computed | |
| id | Yes | Challenge id from the challenge response | |
| signature | Yes | HMAC signature from the challenge response | |
| algo | No | Hash algorithm. Default: 'sha256' | |
| difficulty | No | Leading zero bits required. Default: matches challenge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the return value: a 5-minute HMAC-signed token on success or an error object on failure. It also mentions server-side re-verification. However, it does not cover potential side effects or rate limits.
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?
The description consists of three concise sentences: the first states the purpose, the second details input/output, and the third mentions server-side capabilities. It is front-loaded and free of superfluous content.
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 no output schema, the description adequately explains return values (success token with lifetime, failure reason). It references the sibling 'challenge' and describes the token's re-verification endpoint. However, it lacks detail on possible failure reasons or error codes.
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%, and the description adds valuable context by listing parameters and stating they come from a prior challenge call, plus the agent-computed nonce. This clarifies the origin and usage beyond the schema descriptions.
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 explicitly states 'Verify a PoW solution,' using a specific verb and resource. It clearly distinguishes from sibling tools like 'challenge' by describing input from a prior challenge call and the verification purpose.
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 indicates that input comes 'from a prior challenge call,' implying a sequence (call challenge first, then verify). It does not explicitly state when not to use it or contrast with alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0challengestatusverifyScored across 3 tools
Each tool has a distinct purpose: challenge initiates a PoW challenge, status checks server health and metadata, and verify submits the solution. No overlap in functionality.
All tool names are single-word imperative verbs (challenge, status, verify), following a consistent naming pattern.
Three tools are appropriate for a captcha service, covering the core workflow (challenge, verify) and a status check. Not excessive or insufficient.
The core PoW challenge-verify cycle is complete. However, the status tool mentions a Lightning skip option, but no tool to execute it, which is a minor gap.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
Remote MCP server exposing 330 production AI-agent services for web/data processing, validation, AI utilities, blockchain/crypto utilities, and x402 pay-per-use access.
Hosted MCP server for live public-data APIs and Skills for AI agents.
