validate_integration

io.github.fetchsandbox/mcp · Verify this server

For hosted application_workflow_v1 apps, build and publish the disabled test adapter before requesting short-lived credentials. After installing the existing handoff and republishing, call preflight:true with session_id/run_id. A setup_blocked response is not a failed application test. Its next_tool_call is null: repair its exact host-side blocker first, then call resume_tool_call for the SAME run/preflight without rotating credentials. Do not poll an unchanged setup blocker. Execution has a separate deadline. Never execute twice; retrieve status with session_id/run_id only. If the browser stops at a security challenge, immediately hand the owner the SAME run/order-verified original TEST checkout URL (livemode=false) while observation continues; never bypass the challenge, silently wait, create a replacement checkout or retry Pay. Browser payments require an available browser or one explicit user action, and independently observed paid state; a click is not proof. After proof, remove only temporary settings, republish and verify disabled externally. For every app, inspect capabilities and application_actions. Prepare missing test products, prices and related records before failures: author fixtures using documented provider operations, include a final GET with an exact identity assertion, then configure the app with returned fixture IDs. The server uses the existing twin workflow runner and independently checks read-back. Fixture readiness is not app proof. Unsupported application checks must be reported explicitly, not replaced by a separate script or quickrun. Send application_context with the original goal and inspected workflow to obtain model-proposed rules, missing observations and fixture requirements. Proposals are not executed checks. Preserve all proposed rules in the coverage report, even when unsupported. If server_requirements_model_available is false or planning returns requirements_model_unavailable, inspect the app and author the candidate contract with your own model; label it builder-proposed, not a FetchSandbox model result. Never wait for the human to write routine test requirements. For a normal HTTP app workflow with independently readable state, configure application_workflow_v1 and application_config. Declare a positive baseline first, normal app actions, GET observations and required exact assertions. Reuse the proposed rule IDs; omitted rules remain unmeasured. Signed callback app_response contains a sanitized acknowledgement; response remains delivery metadata. Inspect response_capture_status when the body is missing, and independently read state for the verdict. Signed provider event actions are supported through event_destinations and isolated secure-handoff signing secrets; bind payload identity to actual app responses and verify saved state. No browser, arbitrary auth-header or SQL execution is supported by this HTTP contract: record those gaps explicitly. Do not weaken signature or access checks to make a test pass. Start a validation session for the user's integration. quickrun and run_workflow execute OUR curated workflow against a twin — green there says the provider behaves as documented, and says nothing about whether their integration wired to it correctly. This instead hands back a FRESH twin per provider and asks the user to point their app at it, then reads external provider traffic. Direct agent calls also appear there; caller identity is not established. Use it when someone wants their integration verified before launch. Call once with `providers`, then follow the returned `next_action`. Inspect the app and supply a complete `receipt_config` before configuring the suite; the application suite drives its own purchases and webhooks, so do not ask the user to run a manual flow first. The matrix is returned before any traffic: pass `arm` with a probe ID before exercising the app. Send the returned request_headers on every provider request in that attempt, then pass `probe` and `run_id` to evaluate. Use `cancel: true` with `run_id` to abort or retry failed cleanup. Request logs alone do not prove application state or production readiness. For a supported payment-to-receipt integration, follow the structured `next_action`; call `next_tool_call` only when it is non-null and its arguments are complete. Never execute while host-side setup is pending. Do not substitute guide, quickrun, list_workflows, or reference probes for application verification. Use the widest suite the server recommends. receipt_recovery_v1 includes R1-R4 and adds checks R5-R8 for accepted-send response loss, concurrent redelivery, source/email transient failures and delayed redelivery. Pass suite plus receipt_config with the app's exact webhook URL, test recipients and observable purchase marker. FetchSandbox freezes all four receipt rules for both same-customer and different-customer purchases. You are responsible for completing this setup: treat the target as a disposable test app, not the user's live production service, until its declared suite passes. For a greenfield app, keep live billing disabled and publish a temporary test build first to obtain its stable public origin. Use the published webhook URL, not a private preview URL. Inspect the app and identify the exact webhook route before suite configuration. Before requesting or applying test secrets, send an unsigned POST to that exact URL from outside the workspace; a 400 signature rejection is expected, while a 307/login redirect is a blocker. Keep signature validation enabled. After the successful preflight, configure the suite with its complete receipt_config. Apply the returned twin URLs, X-Flow-Run-Id, and three temporary credentials only to this disposable app; execute only after the host-side setup actions are complete. The credentials are twin-only test values: PADDLE_API_KEY, RESEND_API_KEY, and PADDLE_WEBHOOK_SECRET. Use the platform's supported secret store or secret-writing tool and never use real provider credentials or enable live billing. After every required check is held, remove only the test secrets and twin config this run added, including from the disposable test app's published scope. Never modify a separate live production app or delete pre-existing, shared, or real-provider values. Confirm the temporary names are absent, then hand the app to its owner to configure separate development/staging credentials. If the suite is failing or inconclusive, retain test config for repair and a fresh run. The configure_app response contains public twin URLs/IDs and a secret_handoff_url, never the secret values themselves. If the host exposes no safe way for you to write test secrets, explain that specific limitation and show the human the link to open while signed in to the owning FetchSandbox account; they can copy the three values directly into the platform secret store. Do not ask the human to discover endpoints, call FetchSandbox manually, or paste secret values into chat, project files, or logs. Wait for confirmation only when the human must complete that secure-store action. Then call execute:true with its run_id. FetchSandbox drives signed events and independently observes accepted email records. Keep every check and the observation windows in your report. Restore any temporary host privacy setting after the test. On an inconclusive execute result, inspect and report its `execution_diagnostics` field directly; do not ask the human to infer a cause from the public receipt page, which intentionally omits private proof. If you cannot configure the app, report that blocker; reference tests cannot replace app execution. A verified receipt suite covers only its declared rules and windows, never all production behavior. A missing or untriggered recovery fault stays unmeasured. This application suite requires sign-in. Paddle checkout is a separate app-owned browser flow: if a transaction's `checkout.url` points to `fetchsandbox.com/checkout`, returns 404, or does not show a checkout page, do not imply FetchSandbox hosts the merchant's payment UI. Inspect the exact URL and the Paddle Sandbox default payment link or per-transaction override. Tell the builder to use a reachable app checkout page that loads Paddle.js and opens the `_ptxn` transaction, or a supported Paddle-hosted flow. Verify browser checkout/payment separately from twin API and webhook tests; transaction creation alone is not payment proof.