Cursor and a FetchSandbox account key from https://fetchsandbox.com/keys. The twins are isolated, so you don't need live vendor keys. Never paste real keys into chat.
01
Get your account key
Create a key at https://fetchsandbox.com/keys. Save it privately in your user config. Don't put it in chat or project source.
In ~/.cursor/mcp.json, add a remote mcpServers.fetchsandbox entry. Set its url to https://fetchsandbox.com/mcp/v1 and its Authorization header to Bearer YOUR_FETCHSANDBOX_KEY. Merge the entry in without overwriting other entries. Open MCP settings and enable FetchSandbox. The labels can vary, for example Customize or Tools & Integrations. Restart Cursor if the tools don't refresh. Reference: https://cursor.com/docs/mcp.
Seeing the tools listed doesn't prove a workflow works. Call list_workflows with spec_slug=stripe. It's read-only and confirms the transport. It doesn't prove your application works.
Confirm an actual tool call
Call FetchSandbox list_workflows with spec_slug stripe and tell me the actual result.
04
Verify your running app and inspect a receipt
Run validate_integration. First agree on the behavior you can observe. Then configure your app to call the supplied twins, invoke the app and inspect the receipt. Local apps use managed tunnel transport. Hosted apps need a reachable protected URL.
Verify your running app and inspect a receipt
Use FetchSandbox validate_integration for this running app. Agree the observable expected behavior with me, configure the isolated twins, invoke the actual app and report the receipt, including anything failed or unmeasured. Keep polling the same get_job until it reaches a terminal state.
Signs your setup works
list_workflows with spec_slug=stripe returns a result in Cursor, and your running app produces a receipt from calls it made to the configured twins. A passing reference quickrun doesn't test your code.
Scope of this evidence
The receipt records expected versus actual for the scenarios you agreed on, tested against the twins your app is configured to call, through a managed tunnel for local apps or a reachable protected URL for hosted ones. Related public receipts illustrate workflows. They're separate from verifying your own app here and aren't native Cursor acceptance.
Historical runs recorded against isolated twins. You can inspect each receipt and its evidence. Not a new execution or production certification.
Duplicate charge remediation
Passed
Finance needs to refund customers who were charged twice by a billing incident, quickly and at scale, without refunding a disputed or ambiguous payment and with human approval above set limits.
Each receipt is one individual dated run against isolated provider twins, not live vendors. The caller declared the app revision, and it is not attested. Workflow docs are pinned to the commit shown here. A status appears only when the original verdict, counts, completeness and app_verified all support it, and counts are never merged. Some source exports, including the n8n lead flow, are not public. These public examples are separate from proving your own app through your builder, and they don't show that each native client was tested.
Legal needs to honor data deletion requests across every system before the statutory deadline, while keeping records the law requires and never deleting for an unverified requester.
Each receipt is one individual dated run against isolated provider twins, not live vendors. The caller declared the app revision, and it is not attested. Workflow docs are pinned to the commit shown here. A status appears only when the original verdict, counts, completeness and app_verified all support it, and counts are never merged. Some source exports, including the n8n lead flow, are not public. These public examples are separate from proving your own app through your builder, and they don't show that each native client was tested.
