Open Connectors > Add custom > MCP server. Name it FetchSandbox and choose Direct connection. Enter https://fetchsandbox.com/mcp/v1, put your raw FetchSandbox key in Bearer token or API key, then click Add server. The connector works in the building chat. It is not automatically part of your published app. Docs: https://docs.lovable.dev/integrations/custom-mcp
Remote MCP configuration
Server name: FetchSandbox
Server URL: https://fetchsandbox.com/mcp/v1
Authentication: Bearer token or API key
Token: your raw FetchSandbox account key
FetchSandbox capture · Lovable · 2 Oct 2026. Setup reference. This shows the platform setup, not an execution.
03
Confirm an actual tool call
Seeing the tools listed doesn't prove a workflow works. Ask Lovable to run list_workflows with spec_slug=stripe. It's a read-only connection test.
Confirm an actual tool call
Call FetchSandbox list_workflows with spec_slug stripe and tell me the actual result.
04
Verify the running app and inspect a receipt
Ask Lovable to run validate_integration. Agree on the observable behavior. Point your published app's provider requests at the twins from the validation session, invoke the app, then inspect the receipt. Local apps use managed tunnel transport. Hosted apps need a reachable, protected HTTPS URL.
Verify the 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
In the building chat, Lovable shows an actual list_workflows result for spec_slug=stripe. Then your running app's calls produce a receipt. A passing reference quickrun on its own doesn't test your code.
Scope of this evidence
Your receipt records expected versus actual for the agreed scenarios, tested against the configured twins. Anything outside those scenarios stays unmeasured. Your app's requests have to reach the session's twins. Local apps use the managed tunnel, and hosted apps use a reachable, protected HTTPS URL. Related public receipts show example workflows. They don't verify your own app.
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.
