io.github.fetchsandbox/mcp

Ingest an OpenAPI spec and get a working sandbox you can call immediately. REQUIRED: pass EITHER `url` OR `content` — never just `name` alone (name is a display label, not a lookup). If the user mentions a popular API by name (Stripe, GitHub, Twilio, Notion, OpenAI, etc.), FIRST call `list_specs` with a filter to confirm it's in the catalog, then call import_spec with that vendor's public OpenAPI URL (e.g. Stripe: https://raw.githubusercontent.com/stripe/openapi/master/openapi/spec3.json). The backend content-hashes the spec and auto-matches to the bundled sandbox when applicable. Returns sandbox_id, workflows_preview, and a base_url that proxies schema-validated responses. Private URLs (localhost, 10.x, 192.168.x) are rejected by the backend — use `content` to paste those inline.

List recent workflow runs (and ad-hoc traffic) for a sandbox, newest first. Use when the user asks 'what did I run', 'show me recent validation runs', 'did the stripe test pass earlier', or wants to find a previous run to share or re-inspect. Each run includes its shareable timeline URL (fetchsandbox.com/runs/<sandbox_id>) so the user can open the visual trace in a browser or drop it in Slack / a PR comment. Requires sandbox_id (from import_spec).

Browse the FetchSandbox spec catalog — every API (Stripe, GitHub, Twilio, Notion, OpenAI, Polar, GitLab, and 40+ more) that has a ready-to-use sandbox with curated workflows. Use when the user asks 'what APIs do you support?', 'what specs are available?', 'show me the catalog', 'do you have <X>?', or wants to explore before committing to one. Returns each spec's slug (use as `name` arg to import_spec), description, endpoint count, and tags. Pass `filter` to narrow by substring (e.g., filter='pay' returns Stripe, Paddle, Polar).

List the named, runnable workflows for a previously-imported spec. Workflows are realistic multi-step API journeys (e.g. 'create customer → attach payment method → create subscription'). Use this after import_spec 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. Returns: id, name, description, and step count per workflow.

Execute EVERY workflow (or a scoped subset) for a sandbox in ONE call. Use this — NOT a loop of run_workflow — for any validation-style request: "validate this integration", "run all workflows", "check coverage", "test stripe checkout", "fs validate". IDEs (Cursor, Claude Code) approve each MCP call individually, so 18 workflows via run_workflow = 18 clicks. This tool = 1 click, total. Scope via `workflow_names`: pass an array of workflow ids to run a subset (e.g., user says "validate stripe CHECKOUT" → pass ["create_checkout_session", "checkout_complete"]). Names are case-insensitive; dashes and underscores interchangeable. Returns: summary (pass/fail counts, totals) + full step trace per workflow. After running, the user can visit fetchsandbox.com/runs/<sandbox_id> for a shareable visual timeline.

Execute ONE specific workflow by name and return its step-by-step trace. 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.