FetchSandbox

Un motor de verificación determinista para agentes. Dispara los casos límite que tu sandbox nunca envía, y luego prueba una corrección: el mismo escenario falla en el código antiguo y pasa en el nuevo.

GitHub

Documentación

fetchsandbox-mcp

También en Smithery, npm y el registro oficial de MCP.

Un motor de verificación determinista para agentes, como servidor MCP para FetchSandbox.

Tu agente escribe una integración. Esto comprueba si realmente funciona — contra un sandbox que se comporta como el proveedor real, incluidos los fallos: webhooks reintentados, tarjetas rechazadas, límites de tasa, errores de autenticación.

Cuando encuentra un error, puede proponer una corrección y luego demostrarla: el mismo fallo se ejecuta contra tu código antes y después del diff. Verde solo si se reprodujo primero y se detuvo después. Obtienes una URL de recibo de cualquier manera.

Instalación

El mismo comando stdio en todas partes. npx obtiene la versión actual, así que no hay nada que instalar.

{
  "mcpServers": {
    "fetchsandbox": {
      "command": "npx",
      "args": ["-y", "fetchsandbox-mcp@latest"]
    }
  }
}

Cliente	Archivo
Claude Code	`~/.claude/settings.json`, o `.mcp.json` en el repositorio
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json`
Cursor	`~/.cursor/mcp.json`, o `.cursor/mcp.json` en el repositorio
Zed	`~/.config/zed/settings.json`, bajo `context_servers`
Codex	`~/.codex/config.toml`, como `[mcp_servers.fetchsandbox]`

Reinicia el cliente después. Cualquier otra cosa que hable MCP acepta el mismo comando y argumentos.

Uso

Describe el problema como se lo describirías a un colega. No necesitas nombrar una herramienta.

Los clientes están reportando más asientos de los que compraron después de un pago de Paddle. ¿Puedes averiguar por qué?

El agente trabaja de la siguiente manera: enruta el síntoma, lo reproduce contra el sandbox del proveedor, lee tu código, obtiene una corrección, demuestra la corrección en tu código. Cada paso entrega lo que el siguiente necesita.

Una cosa que vale la pena saber, porque es fácil equivocarse: prove_fix necesita el árbol sin corregir. Ejecútalo antes de escribir el diff en el disco, o no hay error que reproducir ni prueba que obtener.

Cuentas

No necesitas una para empezar. Instálalo, haz una pregunta, y todo funciona.

La primera vez que una ejecución produce algo que vale la pena conservar — un recibo, o un conjunto de hallazgos — recibirás un código corto y un enlace. Iniciar sesión toma unos veinte segundos y hace dos cosas: la evidencia detrás de tus recibos deja de archivarse después de 15 días, y las ejecuciones de esa máquina se recopilan en un solo lugar. Se te preguntará como máximo una vez al día, y nunca una vez que hayas iniciado sesión.

Para CI, o en cualquier lugar donde no haya un navegador disponible, configura una clave en su lugar:

FETCHSANDBOX_API_KEY=fsk_...

La clave se escribe en ~/.fetchsandbox/credentials.json cuando inicias sesión desde un editor; la variable de entorno siempre gana.

Herramientas

Comienza con guide. Elige las correctas para lo que pediste.

Encontrar y corregir

Herramienta	Qué hace	Argumentos
`guide`	Enruta un síntoma a una especificación, flujo de trabajo y clase de fallo conocida	`intent*`, `hints`
`find_bugs`	Audita tu proyecto contra clases de fallo de integración conocidas. No necesita un remoto de git — lee el directorio al que lo apuntes	`path`, `spec`, `timeout_s`
`fix_bug`	Devuelve un `git diff` para un hallazgo. No toca tus archivos	`bug*`, `fix_pattern`, `path`, `spec`, `timeout_s`
`prove_fix`	Ejecuta el fallo contra tu código antes y después del diff. Verde solo con un cambio medido	`diff*`, `bug`, `scenario`, `sandbox_id`, `path`, `timeout_s`

Ejecutar el sandbox

Herramienta	Qué hace	Argumentos
`quickrun`	Ejecuta un flujo de trabajo contra una especificación incluida en una sola llamada. Devuelve `sandbox_id` y `flow_run_id`	`spec_slug`, `workflow_name`, `scenario`
`verify_behavior`	Muestra una clase de fallo en manejadores de referencia — con error vs corregido	`bug_pattern_id*`, `prompt`, `sandbox_id`, `flow_run_id`
`run_workflow`	Ejecuta un flujo de trabajo en un sandbox que ya tienes	`sandbox_id`, `workflow_name`, `scenario`
`run_all_workflows`	Ejecuta varios en una sola llamada	`sandbox_id*`, `workflow_names`
`list_workflows`	Flujos de trabajo disponibles para una especificación	`spec_id*`
`list_runs`	Ejecuciones pasadas para un sandbox	`sandbox_id*`, `limit`

Traer tu propia especificación

Herramienta	Qué hace	Argumentos
`list_specs`	Especificaciones ya disponibles	`filter`
`import_spec`	Ingiere una especificación OpenAPI 3.x por URL o contenido pegado. Devuelve un sandbox invocable	`url`, `content`, `name`
`submit_proof`	Publica un recibo para una ejecución	`sandbox_id`, `flow_run_id`, `bug_pattern_id`, `summary`, `proofs`
`coach`	Ayuda de múltiples turnos para construir una integración	`intent`, `session_id`, `user_response`, `context`

* = requerido.

Qué sale de tu máquina

find_bugs, fix_bug y prove_fix empaquetan el directorio al que los apuntes y lo suben para análisis. Vale la pena decirlo claramente, porque la redacción anterior aquí implicaba lo contrario.

Excluido antes de empaquetar: .git, node_modules y la salida de compilación, archivos de instrucciones del agente, y cualquier cosa con forma de credencial — .env*, *.pem, *.key, id_rsa*, *.tfstate, .npmrc, .aws, .ssh y más.

Luego el archivo se lee de nuevo y se rechaza si todavía contiene algo con forma de credencial viva, dondequiera que esté y como se llame. Una clave en config/local.yml detiene la subida y nombra el archivo. Los patrones solo cubren lo que alguien pensó; el escaneo está ahí para el resto.

Si prefieres que no salga nada en absoluto, el análisis necesita la fuente hoy. Ese es el estado honesto.

Los recibos son públicos para cualquiera que tenga el enlace

submit_proof adjunta las solicitudes y respuestas reales de la ejecución antes/después de tu aplicación a la página del recibo, para que el recibo muestre el comportamiento propio de tu código. Esa página se sirve sin inicio de sesión — ese es el propósito, pegas el enlace en un PR — lo que significa que los cuerpos en ella son legibles por cualquiera que tenga el enlace.

Las sondas se ejecutan contra el gemelo de FetchSandbox, no contra tu proveedor, así que los datos son datos del sandbox. Pero los cuerpos de las solicitudes son los que construyó tu aplicación, y esos pueden llevar valores de tu configuración. Mira un recibo antes de compartirlo.

Configuración

Variable de entorno	Predeterminado	Propósito
`FETCHSANDBOX_API_KEY`	ninguno	Iniciar sesión sin navegador. Anula las credenciales almacenadas
`FETCHSANDBOX_BASE_URL`	`https://fetchsandbox.com`	Apuntar a un backend diferente
`FETCHSANDBOX_TELEMETRY`	activado	Establecer a `0` para desactivar

La telemetría registra un id opaco por máquina (un UUID aleatorio en ~/.fetchsandbox/session.json), el nombre de la herramienta, la latencia y si la llamada tuvo éxito. No contenido de especificaciones, no cuerpos de solicitudes, no credenciales. Así es como contamos sesiones y vemos qué APIs trae la gente.

Una vez que inicias sesión, las llamadas también se atribuyen a tu cuenta — ese es el punto de iniciar sesión, y es lo que permite que tus ejecuciones aparezcan en un solo lugar.

FETCHSANDBOX_TELEMETRY=0 detiene el envío del id por máquina, así que las llamadas ya no están vinculadas a tu máquina. No hace que una llamada sea invisible: el servidor todavía registra que una herramienta se ejecutó, porque es lo que la está ejecutando. Y si has iniciado sesión, tu clave te identifica de todos modos — eso es lo que es una clave. Para no ser atribuido, no inicies sesión.

Licencia

MIT — ver LICENSE.

fetchsandbox.com
Fuente · Problemas