FetchSandbox

Um mecanismo de verificação determinística para agentes. Dispara os casos extremos que seu sandbox nunca envia e, em seguida, comprova uma correção: o mesmo cenário falha no código antigo e passa no novo.

GitHub

Documentação

fetchsandbox-mcp

Também no Smithery, npm e no registro oficial de MCP.

Um mecanismo de verificação determinística para agentes, como um servidor MCP para FetchSandbox.

Seu agente escreve uma integração. Isto verifica se ela realmente funciona — contra um sandbox que se comporta como o provedor real, incluindo as falhas: webhooks reprocessados, cartões recusados, limites de taxa, erros de autenticação.

Quando encontra um bug, pode propor uma correção e depois prová-la: a mesma falha é executada contra seu código antes e depois do diff. Verde somente se reproduziu primeiro e parou depois. Você recebe uma URL de recibo de qualquer forma.

Instalação

O mesmo comando stdio em todos os lugares. npx busca a versão atual, então não há nada para instalar.

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

Cliente	Arquivo
Claude Code	`~/.claude/settings.json`, ou `.mcp.json` no repositório
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json`
Cursor	`~/.cursor/mcp.json`, ou `.cursor/mcp.json` no repositório
Zed	`~/.config/zed/settings.json`, em `context_servers`
Codex	`~/.codex/config.toml`, como `[mcp_servers.fetchsandbox]`

Reinicie o cliente depois. Qualquer outra coisa que fale MCP aceita o mesmo comando e argumentos.

Como usar

Descreva o problema da mesma forma que descreveria para um colega. Você não precisa nomear uma ferramenta.

Clientes estão relatando mais assentos do que compraram após um pagamento no Paddle. Você consegue descobrir o porquê?

O agente trabalha assim: roteia o sintoma, reproduz contra o sandbox do provedor, lê seu código, obtém uma correção, prova a correção no seu código. Cada etapa entrega o que a próxima precisa.

Uma coisa que vale saber, porque é fácil errar: prove_fix precisa da árvore sem correção. Execute antes de gravar o diff no disco, ou não haverá bug para reproduzir e nenhuma prova a obter.

Contas

Você não precisa de uma para começar. Instale, faça uma pergunta, e tudo funciona.

Na primeira vez que uma execução produzir algo que vale a pena manter — um recibo, ou um conjunto de descobertas — você receberá um código curto e um link. Entrar leva cerca de vinte segundos e faz duas coisas: as evidências por trás dos seus recibos deixam de ser arquivadas após 15 dias, e as execuções daquela máquina se reúnem em um só lugar. Você será solicitado no máximo uma vez por dia, e nunca depois de entrar.

Para CI, ou em qualquer lugar onde um navegador não esteja disponível, defina uma chave:

FETCHSANDBOX_API_KEY=fsk_...

A chave é gravada em ~/.fetchsandbox/credentials.json quando você entra a partir de um editor; a variável de ambiente sempre vence.

Ferramentas

Comece com guide. Ela escolhe as ferramentas certas para o que você pediu.

Encontrar e corrigir

Ferramenta	O que faz	Argumentos
`guide`	Roteia um sintoma para uma especificação, fluxo de trabalho e classe de falha conhecida	`intent*`, `hints`
`find_bugs`	Audita seu projeto contra classes de falha de integração conhecidas. Não precisa de remote git — lê o diretório que você apontar	`path`, `spec`, `timeout_s`
`fix_bug`	Retorna um `git diff` para uma descoberta. Não toca nos seus arquivos	`bug*`, `fix_pattern`, `path`, `spec`, `timeout_s`
`prove_fix`	Executa a falha contra seu código antes e depois do diff. Verde somente em uma inversão medida	`diff*`, `bug`, `scenario`, `sandbox_id`, `path`, `timeout_s`

Executando o sandbox

Ferramenta	O que faz	Argumentos
`quickrun`	Executa um fluxo de trabalho contra uma especificação incluída em uma chamada. Retorna `sandbox_id` e `flow_run_id`	`spec_slug`, `workflow_name`, `scenario`
`verify_behavior`	Mostra uma classe de falha em handlers de referência — com bug vs corrigido	`bug_pattern_id*`, `prompt`, `sandbox_id`, `flow_run_id`
`run_workflow`	Executa um fluxo de trabalho em um sandbox que você já tem	`sandbox_id`, `workflow_name`, `scenario`
`run_all_workflows`	Executa vários em uma chamada	`sandbox_id*`, `workflow_names`
`list_workflows`	Fluxos de trabalho disponíveis para uma especificação	`spec_id*`
`list_runs`	Execuções passadas para um sandbox	`sandbox_id*`, `limit`

Trazendo sua própria especificação

Ferramenta	O que faz	Argumentos
`list_specs`	Especificações já disponíveis	`filter`
`import_spec`	Ingere uma especificação OpenAPI 3.x por URL ou conteúdo colado. Retorna um sandbox chamável	`url`, `content`, `name`
`submit_proof`	Publica um recibo para uma execução	`sandbox_id`, `flow_run_id`, `bug_pattern_id`, `summary`, `proofs`
`coach`	Ajuda em múltiplas etapas para construir uma integração	`intent`, `session_id`, `user_response`, `context`

* = obrigatório.

O que sai da sua máquina

find_bugs, fix_bug e prove_fix empacotam o diretório que você aponta e o enviam para análise. Vale dizer claramente, porque o texto anterior aqui implicava o contrário.

Excluídos antes do empacotamento: .git, node_modules e saída de build, arquivos de instrução do agente, e qualquer coisa com formato de credencial — .env*, *.pem, *.key, id_rsa*, *.tfstate, .npmrc, .aws, .ssh e mais.

Depois o arquivo é relido e recusado se ainda contiver algo com formato de credencial viva, onde quer que esteja e como quer que se chame. Uma chave em config/local.yml interrompe o upload e nomeia o arquivo. Padrões apenas cobrem o que alguém pensou; a varredura existe para o resto.

Se você preferir que nada saia, a análise precisa do código-fonte hoje. Esse é o estado honesto.

Recibos são públicos para qualquer pessoa com o link

submit_proof anexa as requisições e respostas reais da execução antes/depois do seu aplicativo à página do recibo, então o recibo mostra o comportamento do seu próprio código. Essa página é servida sem login — esse é o objetivo, você coloca o link em um PR — o que significa que os corpos nela são legíveis por qualquer pessoa que tenha o link.

As sondas rodam contra o gêmeo FetchSandbox, não contra seu provedor, então os dados são dados de sandbox. Mas os corpos das requisições são os que seu aplicativo construiu, e esses podem carregar valores da sua configuração. Olhe um recibo antes de compartilhá-lo.

Configuração

Variável de ambiente	Padrão	Finalidade
`FETCHSANDBOX_API_KEY`	nenhum	Entrar sem navegador. Substitui as credenciais armazenadas
`FETCHSANDBOX_BASE_URL`	`https://fetchsandbox.com`	Apontar para um backend diferente
`FETCHSANDBOX_TELEMETRY`	ativado	Defina como `0` para desativar

A telemetria registra um id opaco por máquina (um UUID aleatório em ~/.fetchsandbox/session.json), o nome da ferramenta, a latência e se a chamada foi bem-sucedida. Não conteúdo de especificação, não corpos de requisição, não credenciais. É assim que contamos sessões e vemos quais APIs as pessoas trazem.

Depois que você entra, as chamadas também são atribuídas à sua conta — esse é o objetivo de entrar, e é o que permite que suas execuções apareçam em um só lugar.

FETCHSANDBOX_TELEMETRY=0 impede que o id por máquina seja enviado, então as chamadas não são mais vinculadas à sua máquina. Isso não torna uma chamada invisível: o servidor ainda registra que uma ferramenta foi executada, porque é ele quem a executa. E se você estiver conectado, sua chave identifica você independentemente — é isso que uma chave é. Para não ser atribuído, não entre.

Licença

MIT — veja LICENSE.