# FetchSandbox (remote · fetchsandbox.com)

A deterministic verification engine for agents. Proves a fix: fails on the old code, passes on new.

- Trust score: 82/100 (high trust)
- Change this week: +10
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-25

## Components

- remote · `fetchsandbox.com`: 82/100 (this document), [markdown](https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1.md), [page](https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1)
- npm · `fetchsandbox-mcp`: 80/100, [markdown](https://verifymcp.io/servers/fetchsandbox-mcp/fetchsandbox-mcp.md), [page](https://verifymcp.io/servers/fetchsandbox-mcp/fetchsandbox-mcp)

## Channel facts

- Endpoint: `https://fetchsandbox.com/mcp/v1`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.7.30`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-25.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 6595 tokens (~824/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 97% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the FetchSandbox MCP server?

FetchSandbox is a hosted endpoint at https://fetchsandbox.com/mcp/v1, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http fetchsandbox-mcp 'https://fetchsandbox.com/mcp/v1'
```

### Cursor

```json
{
  "mcpServers": {
    "fetchsandbox-mcp": {
      "url": "https://fetchsandbox.com/mcp/v1"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "fetchsandbox-mcp": {
      "type": "http",
      "url": "https://fetchsandbox.com/mcp/v1"
    }
  }
}
```

### Codex

```toml
[mcp_servers.fetchsandbox-mcp]
url = "https://fetchsandbox.com/mcp/v1"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "fetchsandbox-mcp": {
      "type": "remote",
      "url": "https://fetchsandbox.com/mcp/v1",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add fetchsandbox-mcp --url 'https://fetchsandbox.com/mcp/v1' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  fetchsandbox-mcp:
    url: "https://fetchsandbox.com/mcp/v1"
```

### Netclaw

```json
{
  "McpServers": {
    "fetchsandbox-mcp": {
      "Transport": "http",
      "Url": "https://fetchsandbox.com/mcp/v1"
    }
  }
}
```

### Vellum

```bash
assistant mcp add fetchsandbox-mcp -t streamable-http -u 'https://fetchsandbox.com/mcp/v1'
```

### Other

```json
{
  "mcpServers": {
    "fetchsandbox-mcp": {
      "type": "http",
      "url": "https://fetchsandbox.com/mcp/v1"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-25 (score 82, +9)

- [security improvement] Stability: fail → pass

### 2026-10-20 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 31 to 34.

### 2026-10-19 (score 72, 0)

- [functional] Server version: 0.7.29 → 0.7.30

### 2026-10-18 (score 72, +1)

- [functional] Server version: 0.7.28 → 0.7.29
- [cosmetic] “validate_integration” reworded the description of “fixtures”

### 2026-10-16 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 18 to 21.

### 2026-10-13 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 11.

### 2026-10-12 (score 69, +1)

- [security] Tool “get_job” rewrote its description, which is the text the model reads
- [security] Tool “validate_integration” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 696 → 819
- [functional regression] Schema quality: 696 → 805
- [functional regression] Schema quality: 696 → 783
- [functional] Server version: 0.7.26 → 0.7.28
- [functional] Server version: 0.7.22 → 0.7.26
- [functional] Server version: 0.7.12 → 0.7.22
- [cosmetic] “validate_integration” added an optional parameter “inspect”
- [cosmetic] “validate_integration” added an optional parameter “reassess”
- [cosmetic] “validate_integration” reworded the description of “application_config”

### 2026-10-10 (score 68, 0)

- [security] Tool “list_workflows” rewrote its description, which is the text the model reads
- [security] Tool “quickrun” rewrote its description, which is the text the model reads
- [security] Tool “validate_integration” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 5023 → 5573
- [functional] Server version: 0.7.11 → 0.7.12
- [functional] New tool “get_job”
- [cosmetic] “list_workflows” added an optional parameter “workflow_name”
- [cosmetic] “validate_integration” reworded the description of “application_context”
- [cosmetic] “validate_integration” reworded the description of “app_base_url”
- [cosmetic] “validate_integration” reworded the description of “run_id”

## MCP tools (8)

### `coach` (~696 tokens)

Conversational integration coach for FetchSandbox. Server-side orchestrator that walks the user through adding an API integration (payments / email / auth / etc.) — intake the goal, elicit domain-aware discovery questions from the spec's brain.yaml, route to the right workflow, prove the contract via FetchSandbox, surface compliance notes. Call this BEFORE any other FetchSandbox tool when the user has an open-ended 'help me add X', 'integrate X', 'test my X integration' ask. BEHAVIOR — strict, do exactly this each turn: If next_action=act_in_app, carry out next_actions with your platform's code, configuration and test tools, then return the results to the same validation session. Do not ask the human to choose routine fault tests, supply missing fixture data you can generate, or copy tool output. Ask only for genuine access, secret-entry constraints or ambiguous business rules. Never claim unsupported checks passed. (1) Say `message_for_user` to the user (verbatim or lightly paraphrased to fit your voice — but don't add new content). (2) If `next_action=wait_for_user` AND `options` is present + non-empty: USE YOUR CLIENT'S NATIVE QUESTION-PICKER TOOL (in Cursor / Claude Code this is `AskUserQuestion`) to render the lettered picker with the `question` text, the `options[].label` as rows, `default_option` as default, and an 'Other...' freeform row when `allow_freeform=true`. When the user picks or types, call coach again with `{session_id, user_response: <picked value or freeform text>}`. (3) If `next_action=wait_for_user` AND no `options`: just wait for free text. (4) If `next_action=call_tool`: invoke `tool_call.tool` with `tool_call.args`, then call coach again with the result in `context`. (5) If `next_action=done`: end the session. For a hosted app-builder request to build or test an integration, keep the user's simple goal intact and let the server route all named providers into one validation session. When FetchSandbox returns twin bindings, treat those as tem…

Input parameters:

- `context` (object): Optional context the LLM brings to the turn — e.g. a summary of the user's repo (if you ran an introspect step), or the result of a previously-instructed `tool_call`.
- `intent` (string): User's free-form integration ask, on the FIRST call only. Pass through verbatim — the server's intent router benefits from the full phrasing.
- `session_id` (string): Returned by a previous coach call. Required on every call after the first.
- `user_response` (string): The user's reply to the previous coach turn's question. Required when the previous turn returned `next_action: wait_for_user`.

### `get_job` (~96 tokens)

Retrieve the SAME running find_bugs, fix_bug, prove_fix, verify_behavior or validate_integration job (including requirements planning). Follow next_tool_call until status is done or error. Never restart the original tool to poll. A proposed plan is not execution proof; a running response is not proof. Only the completed measured verdict and receipt can establish a pass.

Input parameters:

- `job_id` (string, required): Exact job_id returned by the original call.

### `guide` (~241 tokens)

ROUTE a symptom to the provider behaviour that explains it. Use this when the user names a provider or a domain (payments, email, auth, SMS, subscriptions) and you need to know what that provider ACTUALLY does — not what its docs say, and not what can be inferred from reading the integration code. Reading the code tells you what your app does with a field. It cannot tell you what the field MEANS at the provider — whether a line item is a seat count, whether a 200 body carries ok:false, whether an event can arrive out of order. That is the class of bug this routes. Returns {spec, workflow, scenario, confidence, reasoning} plus `next_actions`: a typed list of what to call next, with arguments pre-filled. Follow it rather than improvising the next step.

Input parameters:

- `hints` (object): Optional caller-supplied overrides. Each field short-circuits the corresponding detection step.
- `intent` (string, required): The developer's free-form prompt as they typed it. Don't pre-process or shorten — the router benefits from the full phrasing (capture timing, geo cues, failure mode language).

### `quickrun` (~304 tokens)

Run a curated reference workflow against a KNOWN, bundled spec (stripe, clerk, descope, resend, twilio, and 50+ others) in ONE call — it spins up the sandbox by slug, so you do NOT need import_spec or a sandbox_id first. Use this when exploring the bundled provider contract: call `guide` on their prompt, then call `quickrun` with the returned spec + workflow. To reproduce a failure, pass the `scenario` from guide's matched_bug_pattern.reproduce_with.scenario (e.g. webhook_retries, payment_declined). Returns sandbox_id + flow_run_id — pass BOTH to verify_behavior to inspect the reference behavior — plus a receipt URL. This does not execute or prove the caller's application. For a bug in their project, use find_bugs, fix_bug and prove_fix on that project; do not substitute this reference receipt for an own-code proof. Use run_workflow instead ONLY when you already hold a sandbox_id from import_spec of a custom/private spec.

Input parameters:

- `scenario` (string): OPTIONAL failure scenario to reproduce (e.g. webhook_retries, payment_declined). Take it from guide's matched_bug_pattern.reproduce_with.scenario. Omit for the happy path.
- `spec_slug` (string, required): The bundled spec slug from guide (e.g. 'stripe'). Lowercase.
- `workflow_name` (string, required): The workflow id from guide (e.g. 'accept_payment').

### `validate_integration` (~4239 tokens)

Completion rule: a request to verify an app includes its applicable failure checks without another user prompt. When verification_continuation.required is true, continue in this agent: inspect pending_checks, preserve every declared check and its assertions, implement supported actions, and rerun a fresh attempt. Stop only with measured results or concrete blockers showing the missing capability and attempted evidence. Not run, not armed, and no observer yet are work to finish, not unsupported features. Do not clean up the session or present a final proof while actionable checks remain. Ask the owner only for genuinely missing business decisions, credentials or actions you cannot perform. For a local app, start the actual app and call manage_tunnel with its port; use the returned app_base_url. No ngrok install is needed. The managed relay origin deliberately rejects direct browser/curl requests with 404; after configuration and credential installation, test connectivity with validate_integration preflight instead. Do not interpret that private-origin 404 as an app failure or expose relay credentials. Hosted builders use their published origin. Start with providers (and optional app_base_url), then reuse the returned session_id for application_context, fixtures and attempts. Do not include application_context in the initial session call. Inspect how the actual app or workflow executes before choosing a verification path. If the builder can run that workflow locally, bind its real provider clients to every returned twin URL and the supplied test authentication. Use the returned provider operation contracts to implement those clients; a missing canned workflow does not mean the provider lacks an API operation. The existing arm/probe path does not require a published app or webhook: select a probe from the returned matrix, call arm with session_id, send its request_headers on EVERY provider request across the session, execute the actual workflow entry point, then call…

Input parameters:

- `app_base_url` (string): App origin when FetchSandbox must drive or observe a hosted HTTP suite. Optional for a provider-backed workflow executed by the builder through arm/probe; that path does not require a published app o…
- `application_config` (object): Frozen HTTP app drive/read-back contract: 1-30 checks, 1-20 actions per executable check, at most 300 declared actions in total, below 64 KiB. Preserve intermediate reads within these bounds; do not…
- `application_context` (object): Bounded inspected app summary, not credentials or raw code. The existing requirements model proposes rules; it cannot issue a verdict. Requires sign-in and an existing session_id: start with provider…
- `arm` (string): Probe ID from the matrix to arm before running the app. Requires session_id.
- `cancel` (boolean): Abort the attempt or retry failed cleanup. Requires session_id and run_id; cannot combine with arm or probe.
- `execute` (boolean): Drive the configured app and evaluate the frozen receipt suite. Requires session_id/run_id; configuration acknowledgment alone is not proof. Starts the existing backend job asynchronously and returns…
- `fixtures` (object): Prepare session-owned twin data before app tests. Requires session_id. Stable id makes repeated calls replay-safe. Every step names spec, method and relative path. Use {{step1.id}} for dependencies.…
- `inspect` (object): Read fixture inputs through MCP using session_id. Prefer this MCP read to extracting a key for direct HTTP: the edge can reject a generic Python user agent even with valid ownership. This path keeps…
- `preflight` (boolean): Read-only public readiness check for a configured application_workflow_v1. Requires session_id/run_id. Checks frozen empty baseline and token enforcement without creating orders, injecting faults or…
- `probe` (string): Probe ID from the matrix to evaluate after running the app. Requires session_id and run_id.
- `providers` (array): Provider slugs the app integrates, e.g. ['stripe'] or ['paddle','resend']. For provider-free HTTP workflows, omit providers and pass app_base_url.
- `reassess` (boolean): Set true when the user asks to reassess/recontract an app. Requires suite=application_workflow_v1 and application_config.scope_review for EVERY candidate check. Freeze a fresh contract scoped to insp…
- `receipt_config` (object)
- `run_id` (string): Attempt ID returned by arm or suite configuration. Required with probe, cancel, execute or preflight; prevents stale calls from consuming a newer attempt.
- `session_id` (string): Returned by the first call. Pass it back after their app has run a flow to see what it did.
- `suite` (string): Configure the declared application receipt suite on this session.

### `list_workflows` (~339 tokens)

List the named, runnable workflows for a known provider slug or imported spec. Workflows are realistic multi-step API journeys (e.g. 'create customer → attach payment method → create subscription'). Known provider slugs need no import. Use this for exploration ("what can I do?", "show me the flows") OR before run_all_workflows when the user wants a SCOPED validation: list, filter by user intent ("checkout", "webhooks"), then pass the matching ids as `workflow_names` to run_all_workflows. Default results are summaries. Pass workflow_name with an exact returned id or name to inspect that workflow's full definition, including request bodies, assertions, outcomes and invariants; this does not execute it. Returns the workflows AND the failure scenarios this spec can simulate — each with a plain description and the exact call to run it. When cross_service_available is present, use each exact run_with invocation: cross-provider workflows use the returned namespace, not this provider's slug. These curated workflows exercise provider behavior; they do not verify the user's app. Choose relevant scenarios from the inspected workflow and user goal; ask only about ambiguous business requirements. Do not guess scenario names.

Input parameters:

- `spec_id` (string): The spec_id returned by import_spec.
- `spec_slug` (string): A human name like 'resend' or 'stripe'. Use this when you do not have a spec_id — you do not need to look one up first.
- `workflow_name` (string): Exact workflow id or name returned by this catalog. Returns its full definition, including steps and outcome rules, without executing it; omit for summaries.

### `run_workflow` (~328 tokens)

Execute ONE specific workflow by name and return its step-by-step trace PLUS a `share_url` — a public, replayable proof URL that renders the full timeline (every request, response, webhook event) for this run. The share_url is the canonical 'here's what happened' artifact: surface it verbatim in any reply that needs evidence (PR comments, Slack threads, blog posts, X replies). Do NOT substitute a docs URL or any other link as the proof — the share_url is the only valid receipt. Use ONLY when the user explicitly names a single workflow to run (e.g., "run accept_payment", "just check the refund workflow"). For ANY validation-style request — "validate stripe", "check coverage", "run all workflows", "test this integration", or even "validate stripe checkout" (multiple workflows match "checkout") — use `run_all_workflows` instead. The batch tool collapses N approvals to 1 and supports a workflow_names filter for scope. Calling this in a loop is an anti-pattern.

Input parameters:

- `sandbox_id` (string, required): The sandbox_id returned by import_spec.
- `scenario` (string): OPTIONAL failure scenario to exercise (e.g. payment_declined, insufficient_funds, fraud_hold). Toggles the sandbox engine's scenario for the duration of the run, then restores. Use this for 'test wit…
- `workflow_name` (string, required): Workflow id or name from list_workflows. Case-insensitive; dashes and underscores are interchangeable.

### `verify_behavior` (~352 tokens)

Prove a known fix survives a bug — the 'prove' half of reproduce→prove. The backend spawns a buggy AND a fixed reference handler and fires the bug_pattern's probes at both, returning the side-by-side diff (e.g. the buggy handler double-charges on a duplicate webhook, the fixed handler dedupes). Call this AFTER run_workflow reproduces a failure, when the matched bug_pattern has a simulation block, to show the fix actually holds — not just that the failure reproduced. Pass sandbox_id + flow_run_id from the run so the diff is saved onto that run's receipt URL. bug_pattern_id comes from guide's matched_bug_pattern. The buggy/fixed handlers are FetchSandbox reference implementations, NOT the user's code. A confirmed reference result does not verify the user's app or show that it is ready to ship. Keep the returned provider and evidence scope with any reported result.

Input parameters:

- `bug_pattern_id` (string, required): The bug_pattern to prove (e.g. webhook_duplicate_side_effect). Comes from guide's matched_bug_pattern.id or the spec's brain.
- `flow_run_id` (string): OPTIONAL. The flow_run_id returned by run_workflow. Pass with sandbox_id so the receipt URL renders the diff alongside the steps.
- `prompt` (string): OPTIONAL. The user's own description of the symptom. For patterns that can originate in the handler OR the provider, this classifies which side to simulate. Omit to run both.
- `sandbox_id` (string): OPTIONAL. The sandbox from the run. Pass with flow_run_id to save the diff onto that run's receipt. This binds the pattern to that sandbox's provider; provide it when verifying a provider integration.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1#diagnostics

## Score history

- 2026-10-25: 82
- 2026-10-24: 73
- 2026-10-23: 73
- 2026-10-22: 73
- 2026-10-21: 73
- 2026-10-20: 73
- 2026-10-19: 72
- 2026-10-18: 72
- 2026-10-17: 71
- 2026-10-16: 71
- 2026-10-15: 70
- 2026-10-14: 70
- 2026-10-13: 70
- 2026-10-12: 69
- 2026-10-10: 68
- 2026-10-07: 68
- 2026-10-04: 69
- 2026-10-03: 69
- 2026-10-02: 69
- 2026-10-01: 69
- 2026-09-30: 69
- 2026-09-29: 57
- 2026-09-28: 69
- 2026-09-27: 70
- 2026-09-26: 70
- 2026-09-25: 70
- 2026-09-24: 71
- 2026-09-23: 71
- 2026-09-22: 70
- 2026-09-21: 70

## Common questions

### What is the FetchSandbox MCP server?

FetchSandbox is an MCP server listed in the public MCP registry as io.github.fetchsandbox/mcp. A deterministic verification engine for agents. Proves a fix: fails on the old code, passes on new. This page covers its hosted endpoint (https://fetchsandbox.com/mcp/v1).

### Is the FetchSandbox MCP server safe to use?

FetchSandbox scores 82 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the FetchSandbox MCP server expose?

FetchSandbox exposes 8 tools: coach, get_job, guide, quickrun, validate_integration, and 3 more. Their descriptions and schemas cost roughly 6,595 tokens of context every time the server is loaded.

### Does the FetchSandbox MCP server require authentication?

No. We connected to FetchSandbox without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the FetchSandbox MCP server still maintained?

FetchSandbox is still listed as active in the MCP registry. We last reached this channel on 25 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://fetchsandbox.com/mcp/v1
- Repository: https://github.com/fetchsandbox/mcp
- Website: https://fetchsandbox.com/
- Changelog RSS feed: https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1.xml
- Changelog JSON feed: https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1.json
- HTML version of this page: https://verifymcp.io/servers/fetchsandbox-mcp/mcp-v1