Twin reference

​

MCP tools

​

Twin links

​

Box

• Box v2.0 file and folder APIs, including list, upload, download, update, delete, search, and event streams.
• OAuth token exchange, refresh tokens, developer tokens, and downscoped token restrictions.
• Webhook registration, signed webhook delivery attempts, retries, replay, and admin inspection.
• Unified storage and HRIS bridge behavior for apps that reach Box through Unified.

• Preview, thumbnail, transform/export, and advanced enterprise permissions are approximated rather than fully implemented.
• Unsupported webhook triggers, folder sort keys, search sort keys, event stream types, or downscope scopes return structured 400 or 403 responses.
• Arbitrary MIME uploads are stored as opaque content when the twin does not model preview or conversion behavior.

​

Datadog

• Datadog v1/v2 APIs for monitors, dashboards, events, log intake/search/aggregation, metrics, SLOs, downtime, incidents and attachments, Synthetic API tests and results, and notebooks.
• Datadog Pup CLI 1.12.1 request and response contracts across common monitoring and investigation workflows.
• API/application-key or bearer-token authentication, Datadog-shaped errors, rate-limit headers, fault injection, deterministic account state, and admin reset/state routes.
• A small browsable Datadog-style overview for inspecting twin state.

• Cloud integrations, IAM and key management, security, RUM, APM, traces, DBM, workflows, usage/cost, service catalog, on-call, and other unlisted product configuration APIs are not implemented.
• Unknown API paths return 404; they do not return synthetic success.

arga twin-runs create --twins datadog --ttl 60 --wait

​

Discord

• Discord API v10 routes for guilds, channels, messages, reactions, threads, members, roles, bans, invites, webhooks, emojis, stickers, scheduled events, stage instances, auto-moderation rules, soundboard sounds, guild templates, and user endpoints.
• Bot-token authentication, deterministic seeding, admin state inspection, event delivery, replay, and webhook subscriptions.
• Message creation with multipart/form-data file uploads using files[n] or file parts plus payload_json or content.
• Configurable server boost levels for upload-size and emoji-slot limits.

• Channels, roles, members, and messages start empty unless seeded or created through API calls.
• Behavior focuses on REST API compatibility and event delivery; real Discord gateway/websocket behavior is not the primary fidelity target.
• Unsupported or malformed request shapes return Discord-style validation errors rather than silently succeeding.

​

Dropbox

• Dropbox API v2 file operations including list, upload, download, copy, move, delete, search, revisions, tags, upload sessions, and batch operations.
• Sharing APIs for shared links, shared folders, file members, file requests, file properties, and team/admin management.
• Webhook delivery, event replay, seeded team members, a starter folder tree, and account tier-based storage quotas.

• Some advanced Dropbox surfaces are represented through deterministic in-memory behavior rather than full production infrastructure.
• Uploads that exceed configured account-tier quotas return an insufficient_space error.
• Routes outside the modeled Dropbox API v2 surface may return structured non-support rather than a stateful response.

​

GitHub

• GitHub REST API operations for repositories, branch-aware file contents, pull requests, issues, branches, commits, check runs, check suites, git references, labels, pull request reviews, review comments, commit statuses, search, organizations, users, and webhooks.
• Raw file downloads served as public content (no bearer token required) for both https://raw.githubusercontent.com/{owner}/{repo}/{ref}/{path} and https://github.com/{owner}/{repo}/raw/{ref}/{path}. The twin gateway intercepts raw.githubusercontent.com and the resolver matches the longest known branch prefix so slash-containing branch names (for example, feature/deep) and refs/heads/... / HEAD/... refs are handled correctly. Responses use the file’s guessed MIME type (defaulting to application/octet-stream).
• GitHub App endpoints for installations, access tokens, repository listings, app metadata (GET /app, GET /apps/{app_slug}), and the GitHub App manifest registration flow for creating multiple GitHub Apps at runtime (GET/POST /settings/apps/new, GET/POST /organizations/{org}/settings/apps/new, POST /app-manifests/{code}/conversions).
• Multi-app support: each installation is scoped to its owning GitHub App, JWT and installation tokens resolve the correct app, and per-app bot users, webhook secrets, and RSA key pairs are tracked independently.
• Deterministic seeding for repos, files, issues, PRs, checks, and GitHub App configuration.
• Token authentication, OAuth flows, scope enforcement, signed webhook delivery, admin state export, and stub-hit tracking.
• GitHub CLI (gh) and GitHub MCP server compatibility. The twin accepts requests at the standard api.github.com paths as well as the GitHub Enterprise-style /api/v3/... REST prefix and the /api/graphql endpoint, so gh and MCP clients can be pointed at the twin’s base URL without code changes.
• Extended REST coverage used by gh and the MCP server: GET /meta, GET /rate_limit, GET /zen, GET /api/v3, repository archives (/zipball/{ref}, /tarball/{ref}), releases, search for repositories, users, issues, and code, gists (list, get, create, update, delete), notifications and thread subscriptions, projects v2 (org and user fields and items), org and repo Actions workflows, workflow runs, jobs, and artifacts, Actions cache, variables, and secrets, codespaces (list, get, update, stop, delete, ports), user SSH and signing keys, GPG keys, starred repositories, sub-issues and issue types, repository security advisories, global security advisories, Dependabot alerts, code scanning alerts, and secret scanning alerts.
• GraphQL surface at POST /graphql (also reachable through POST /api/graphql) covering the queries and mutations used by gh and the GitHub MCP server, including viewer, repository, issue, and pull request lookups, search, and the corresponding mutations backed by the same store as the REST handlers.

1. Provision the github twin and seed at least one user or organization plus the repositories your app should see.
2. Point your app’s GitHub API and web URLs at the provisioned twin. The wizard handles the standard api.github.com, github.com, and raw.githubusercontent.com rewrites automatically.
3. Register a GitHub App with the manifest flow at GET or POST <github_twin_url>/settings/apps/new, or use GET or POST <github_twin_url>/organizations/{org}/settings/apps/new for an org-owned app. Exchange the returned code with POST <github_twin_url>/app-manifests/{code}/conversions to receive the app id, client id, client secret, webhook secret, and PEM private key.
4. Install the app through the browser flow at <github_twin_url>/apps/{app_slug}/installations/new. Choose the account, repository access, optional webhook URL, and optional webhook secret.
5. For a programmatic setup, create the installation with POST <github_twin_url>/admin/installations using account, app_slug or app_id, repository_selection, optional repositories, optional webhook_url, and optional webhook_secret.
6. From your app, sign a GitHub App JWT with the returned private key, call POST /app/installations/{installation_id}/access_tokens, and use the returned installation token for repository, issue, PR, check, and webhook workflows.

• Endpoints without a full stateful implementation return explicit stub responses with X-Twin-Stub, _twin_stub, and _twin_warning.
• Stub hits can be audited through GET <admin_url>/admin/stub-hits and cleared with POST <admin_url>/admin/stub-hits/clear.
• The GraphQL surface targets the operations used by gh and the official GitHub MCP server. Queries and mutations outside that set may return structured stub responses.
• Strict 100% live gh and MCP coverage is gated by external GitHub fixtures and explicit mutation consent flags. The scripts/validate_github_cli_mcp_compat.py verifier reports any remaining blockers directly.

​

GitLab

• GitLab REST API v4 routes for users, groups, namespaces, projects (by numeric ID or full path), repository branches, files, and commits, issues, merge requests, notes, discussions, pipelines, pipeline schedules, jobs, job artifacts, and project hooks.
• glab api style REST and GraphQL workflows, including a minimal GraphQL surface for glab api graphql calls.
• GitBeaker SDK-style calls, including package routes served outside /api/v4 (/projects/..., /groups/..., /packages/...) and GitLab-shaped fallback responses for unmodeled endpoints on resolved projects.
• GitLab MCP-compatible JSON-RPC over /api/v4/mcp and /mcp, with tools for projects, issues, merge requests, files, and pipelines.
• Token authentication via Authorization: Bearer ..., PRIVATE-TOKEN, JOB-TOKEN, or private_token query parameters. Tokens match GitLab client expectations; no external authentication is performed.
• Admin endpoints to inspect and reseed state (/admin/reset, /admin/state, /admin/clock, /admin/fidelity) and a liveness check at GET /healthz.

• Users, groups, projects, branches, files, commits, issues, merge requests, pipelines, jobs, and hooks start empty unless seeded through config or scenario seeding, or created through API calls.
• The REST /api/v4 surface, glab CLI compatibility, GitBeaker SDK compatibility, and the MCP JSON-RPC tools listed above are the fidelity target; other GitLab surfaces may be approximated or absent.
• Delete operations on seeded resources are non-destructive by design so SDK and CLI probes remain repeatable. To remove state, use the admin reset endpoint rather than relying on a DELETE to drop seeded entities.
• State is process-local and is discarded when the Twin Run ends.

​

Gmail

• Gmail API workflows for inboxes, threads, messages, drafts, labels, attachments, search, send behavior, and watch events.
• OAuth-style token handling, seeded mailbox state, deterministic message/thread IDs, and resettable state for repeatable email-agent tests.
• File attachment metadata and download flows for agents that inspect or transform message attachments.

• Mailboxes start empty unless seeded or populated by the app under test.
• Delivery, spam classification, and provider reputation behavior are deterministic approximations rather than live Gmail infrastructure.
• The twin focuses on Gmail API-compatible agent workflows; broad Google Workspace admin behavior is outside the primary fidelity target.

​

Google Calendar

• Google Calendar API v3 calendars, calendar list, events, ACL rules, settings, colors, and free/busy queries.
• Watch channels and webhook delivery for events, ACL, calendar list, and settings resources.
• Calendar CRUD, event import, quick-add, instances, move operations, and delete flows.

• Calendar and event state starts empty unless seeded or created by the app under test.
• Advanced Google Calendar edge cases outside the modeled v3 resources may be approximated or return structured errors.
• Watch delivery is deterministic and inspectable, which is useful for tests but not identical to every production timing detail.

​

Google Docs

• Google Docs v1 document create, get, and atomic batchUpdate operations.
• UTF-16 document indexes, text insertion and deletion, replace-all, text and paragraph styling, and named ranges.
• A Docs v1 Discovery document rewritten to the provisioned twin URL.
• A browsable Docs-style home and document editor with blank-document creation, autosave, bold, italic, underline, sharing, and document export.
• The preset document ID google-docs-launch-notes, which matches the corresponding file metadata in the default Drive twin.

• This provision contains the Docs API and editor UI only. Provision google_drive for Drive metadata and file operations, and google_sheets for spreadsheet editing.
• The editor focuses on common document workflows. It does not model real-time multi-user cursors, full version history, or every consumer Docs command.

arga twin-runs create --twins google_docs --ttl 60 --wait

​

Google Drive

• Google Drive API v3 files, permissions, revisions, comments, replies, shared drives, changes, watch channels, and simple, multipart, and resumable uploads.
• File operations such as list, get, create, update, copy, delete, export, download, labels, permissions, and generated IDs.
• Preset metadata for google-docs-launch-notes and google-sheets-launch-plan, matching the default resource IDs in the separately provisioned editor twins.
• Google API client compatibility through a Drive discovery document.
• OAuth scope enforcement, change polling, watch notifications, deterministic retries, replay, and storage tier-based quotas.

• The Drive q query language and orderBy support are intentionally a subset; unsupported clauses or keys return 400 invalidQuery.
• Unsupported export formats return 400 cannotExportFile; Google-native exports focus on common document, sheet, slide, form, script, site, and drawing formats.
• HMAC notification signatures are a twin-only optional approximation and are disabled by default.
• Upload MIME types are accepted broadly, but preview, thumbnail, edit, export, and search capabilities depend on the modeled MIME class.
• The Google Docs and Google Sheets editor twins are not part of this provision. Request google_docs and google_sheets separately for their APIs and UIs. People, Workspace Events, Apps Script, and Pub/Sub are under google_workspace.

​

Google Sheets

• Google Sheets v4 spreadsheet creation and reads, A1 values get/update/append/clear and batch methods, sheet mutation batches, formulas, formatting, and developer metadata.
• A Sheets v4 Discovery document rewritten to the provisioned twin URL.
• Deterministic spreadsheet content with auth, ACL, failure, rate-limit, and reset behavior.
• A browsable Sheets-style home and spreadsheet editor with blank-spreadsheet creation, editable cells, a formula bar, sheet tabs, autosave, sharing, and CSV, XLSX, and PDF export.
• The preset spreadsheet ID google-sheets-launch-plan, which matches the corresponding file metadata in the default Drive twin.

• This provision contains the Sheets API and editor UI only. Provision google_drive for Drive metadata, google_docs for document editing, and google_workspace for People, Workspace Events, Apps Script, and Pub/Sub.
• The editor focuses on common grid workflows. It does not model charts, pivot-table editors, macros, or real-time multi-user cursors.

arga twin-runs create --twins google_sheets --ttl 60 --wait

​

Google Workspace

• Google People v1 contacts, contact groups, other contacts, profile reads, and search.
• Google Workspace Events v1 subscriptions, operations, reactivation, event-type filters, task streams, and push-notification helpers.
• Google Apps Script v1 projects, content, versions, deployments, processes, and script execution.
• Cloud Pub/Sub topic, subscription, pull, acknowledge, and IAM helpers used by Workspace event workflows.
• People, Workspace Events, and Apps Script Discovery documents.

• This grouped API-only twin does not publish Drive, Docs, Sheets, Gmail, or Calendar routes. Provision those service twins separately.
• State and event delivery are deterministic approximations intended for repeatable tests, not a live Google Cloud project.

arga twin-runs create --twins google_workspace --ttl 60 --wait
arga twin-runs create --twins google_workspace,google_sheets --ttl 60 --wait

​

Jira

• Jira Cloud REST API v3 issue flows: create, read, update, delete, bulk create, transitions, changelog, edit metadata, comments, worklogs, attachments, issue links, properties, votes, watchers, and search/JQL.
• Projects, users, components, versions, remote links, filters, dashboards, groups, fields, priorities, resolutions, statuses, status categories, issue types, server info, attachment metadata, and webhooks.
• Jira Software Agile endpoints for boards, sprints, board sprints, and backlog issue moves.
• OAuth 2.0 authorization code grant, scope enforcement, deterministic seeding, ADF storage for descriptions/comments, and HMAC-signed webhook delivery.

• The v2 and latest REST aliases route to the v3-compatible implementation; exact historical differences between Jira API versions are not the fidelity target.
• Plain-string descriptions and comments are auto-wrapped in a minimal Atlassian Document Format document.
• Complex JQL behavior is modeled for deterministic testing, but edge cases outside the supported parser may return structured validation errors.

​

Notion

• Notion API routes for users, search, pages, databases, data sources, blocks, comments, file uploads, views, OAuth token exchange, introspection, and revocation.
• Deterministic workspace state, bot identity, pagination, markdown projection, nested page content, database/data-source querying, event outbox, webhook delivery, replay, and admin inspection.
• Workspace plan limits for file uploads and guests, plus capability-based user information visibility.

• Pages, databases, and users start empty unless seeded or created through API calls.
• Unsupported property template types and unsupported database property filters return validation errors.
• Requests outside supported /v1 routes return Notion-style invalid request errors rather than generated mock success responses.

​

Salesforce

• Salesforce REST discovery, sObject CRUD, describe metadata, relationship reads, and updated/deleted feeds under /services/data/v{version}.
• Accounts, Contacts, Cases, Leads, Opportunities, Tasks, Events, templates, messages, custom objects, and the standard fields needed for CRM ingestion.
• Governance objects: Organization, User, Profile, UserRole, PermissionSet, PermissionSetAssignment, ObjectPermissions, FieldPermissions, Group, GroupMember, AccountShare, OpportunityShare, LeadShare, ContactShare, AccountTeamMember, OpportunityTeamMember, Territory2Model, Territory2, UserTerritory2Association, ObjectTerritory2Association, PermissionSetGroup, PermissionSetGroupComponent, UserRecordAccess, EntityDefinition, and RecordType.
• Relationship objects: OpportunityContactRole, AccountContactRelation, and EventRelation.
• SOQL child subqueries and multiple-level parent paths, comparison and IN filters, ordering, LIMIT, and pagination. Use Sforce-Query-Options: batchSize=200 to exercise nextRecordsUrl. Positive values below 200 are raised to 200; the maximum is 2,000. Repeat the header on each page request, or the page size defaults to 2,000. LIMIT caps the complete result rather than setting a page size.
• Stateful Bulk v1 JSON jobs and batches with X-SFDC-Session, including the insert/update/upsert/delete flow used by simple-salesforce. Bulk v2 CSV ingest applies uploaded rows when you set state to UploadComplete and exposes successful, failed, and unprocessed row results. When upserting by Id, a blank Id inserts a new record.
• Bulk v2 query CSV results with Accept: text/csv, maxRecords, and locator. Follow Sforce-Locator until its value is null; Sforce-NumberOfRecords reports the page count. Existing JSON result clients remain supported.
• Composite batch version-relative URLs, references in Composite/graph bodies and URLs, graph rollback, and collection external-ID upsert at PATCH /composite/sobjects/{object}/{externalField}.
• External-ID upserts return 201 when creating and 200 when updating, with id, success, errors, and created in the response. Later graph requests can reference the returned ID for either outcome.
• OAuth authorization-code login/consent, PKCE, client credentials, username/password, refresh and signed JWT bearer grants. OAuth clients and accounts share the twin’s record and permission state. Users in one org share records while separate orgs remain isolated.
• SOSL search, invocable case/email actions, Tooling API discovery, and scenario-defined custom objects, fields, record types, layouts, tabs, and apps.

​

Default OAuth credentials

​

Scenario configuration

{
  "salesforce": {
    "org_id": "00DACME00000001AAA",
    "user_id": "005ACME00000001AAA",
    "username": "reader@acme.example",
    "roles": [{"id": "reader", "name": "CRM Reader"}],
    "profiles": [{
      "name": "CRM Reader",
      "api_enabled": true,
      "object_permissions": {"Account": {"read": true}},
      "field_permissions": {"Account.Name": {"read": true}}
    }],
    "sharing_defaults": {"Account": {"access": "Private"}},
    "oauth_accounts": [{
      "org_id": "00DACME00000001AAA",
      "user_id": "005ACME00000001AAA",
      "username": "reader@acme.example",
      "profile": "CRM Reader",
      "role_id": "reader",
      "records": [{"object": "Account", "alias": "customer", "values": {"Name": "Acme Customer"}}]
    }]
  }
}

​

Sharing-rule metadata

GET /services/data/v67.0/metadata/sharingRules/Account
Authorization: Bearer <access_token>

​

Known limitations

• The catalog covers the fields described above and scenario-defined extensions, not every standard field in every Salesforce edition. Unknown objects and undeclared fields return Salesforce-shaped errors; custom unique and length constraints are enforced.
• Business records start empty. The default org, authenticated User, and schema catalog are available for governance queries. Seed CRM records through Scenarios or create them through the API.
• Permission-set muting, criteria-based sharing-rule execution, restriction rules, full implicit sharing, and advanced territory inheritance are not modeled.
• SOAP Metadata, Bulk v1 XML, hard-delete, Apex REST, Streaming, and Einstein APIs remain outside this surface. Unsupported SOQL expressions fail explicitly.
• Salesforce APIs are the twin surface; there is no Lightning CRM UI. The OAuth login and consent pages support authentication tests.
• API responses include a simulated Sforce-Limit-Info header. The configured API version does not imply complete coverage of that Salesforce release.
• Twin Run TTL is an Arga plan entitlement: Free runs are limited to 10 minutes; eligible paid plans can request up to 480 minutes. OAuth token lifetimes do not extend the Twin Run.

​

Linear

• The Linear GraphQL endpoint at POST /graphql for teams, projects, cycles, issues, labels, comments, workflow states, users, organization, and webhooks.
• Personal API keys sent directly in the Authorization header, plus OAuth 2.0 tokens issued via /oauth/authorize, /oauth/token, and /oauth/revoke.
• @linear/sdk wire compatibility including __typename on entities, { id } relation payloads in default selections, and SDK-shaped GraphQL error envelopes.
• Webhook registration and replay flows, with Linear-Signature, Linear-Delivery, Linear-Event, and Linear-Timestamp headers on deliveries.
• Admin endpoints for state inspection, config updates, reset/clock control, webhook replay, and fidelity checks.

• Teams, projects, cycles, issues, labels, comments, tokens, and webhook subscriptions start empty unless seeded or created through API calls.
• The fidelity target is the GraphQL surface used by Arga workflows and the @linear/sdk, not every Linear feature or internal UI behavior.
• The Linear twin is backend-only — there is no browsable UI surface in the Arga app.

​

Slack

• Slack Web API methods for conversations, channels, messages, scheduled messages, users, reactions, pins, bookmarks, do-not-disturb, modal views, direct messages, and files.
• Block Kit messages on chat.postMessage: requests with a non-empty blocks array are accepted even when fallback text is blank or whitespace, and the submitted blocks are returned in the response and persisted in conversation history. Posts with both empty text and empty blocks still return no_text.
• Auth methods including api.test, auth.test, auth.revoke, and auth.teams.list.
• OAuth 2.0 authorization code grant through /oauth/v2/authorize and /api/oauth.v2.access, plus MCP OAuth aliases at /oauth/v2_user/authorize and /api/oauth.v2.user.access.
• Bot, user, and enterprise-style tokens, method-level OAuth scope enforcement, configurable token scopes, and missing-scope errors.
• File uploads, external upload completion, downloadable files, file-share events, workspace tier constraints, storage quotas, rate-limit simulation, event delivery, replay, and admin inspection.
• Slack CLI app management surface including manifest validate/create/update/export, app status, developer install/uninstall, app delete, connections open, hosted package upload placeholders, hosted environment variables (add/list/remove), and Slack CLI secondary API families covering activities, auth tickets and token rotation, app approvals, external auth, datastores, workflow triggers, function permissions, collaborators, icons, certified installs, and developer sandboxes. Point the Slack CLI at the twin by setting SLACK_API_URL to the twin’s /api/ base.
• Slack MCP Streamable HTTP endpoint at /mcp with JSON-RPC 2.0 initialize, tools/list, and tools/call, OAuth protected resource metadata at /.well-known/oauth-protected-resource/mcp, authorization server metadata at /.well-known/oauth-authorization-server, and Slack-shaped MCP tools (slack_search_messages, slack_search_messages_and_files, slack_search_public_and_private, slack_search_public, slack_search_files, slack_search_users, slack_search_channels, slack_list_channels, slack_read_channel, slack_send_message, slack_schedule_message, slack_send_message_draft, slack_read_thread, slack_list_users, slack_get_user, slack_read_user_profile, slack_create_canvas, slack_update_canvas, slack_read_canvas) that share state with the Web API surface.

• Channels start empty unless seeded or created through conversations.create.
• File upload limits and workspace features are controlled by the twin’s configured tier and constraints, not by a live Slack workspace.
• The REST, OAuth, Slack CLI, and Slack MCP surfaces are the fidelity targets; websocket/Socket Mode behavior is not described as primary support here.
• Hosted package upload endpoints (apps.hosted.generatePresignedPost, apps.hosted.upload) accept the CLI lifecycle but do not execute hosted runtimes.

​

Stripe

• Stripe API v1 resources for customers, payment methods, payment intents, setup intents, charges, refunds, disputes, subscriptions, invoices, invoice items, credit notes, products, prices, plans, coupons, promotion codes, tax rates, shipping rates, tokens, sources, payouts, balance, balance transactions, billing meters, meter events, events, files, checkout sessions, payment links, quotes, billing portal sessions, subscription items, schedules, usage records, tax IDs, webhook endpoints, mandates, and test clocks.
• Stripe-compatible authentication errors, idempotency keys, signed webhooks, test cards for declines and 3D Secure, checkout pages, billing portal pages, dashboard pages, product catalog, and customer management.
• Seed endpoint for starter product, price, and webhook setup.
• Stripe MCP-compatible JSON-RPC server at POST /mcp (and POST /mcp/v1) for use by MCP clients and the @stripe/mcp CLI bridge. The twin routes mcp.stripe.com through this endpoint and serves Stripe’s OAuth discovery documents at GET /.well-known/oauth-protected-resource, GET /.well-known/oauth-protected-resource/mcp, and GET /.well-known/oauth-authorization-server. Implements initialize, notifications/initialized, tools/list, and tools/call, advertising the same 31 tools as the official Stripe MCP server (search_stripe_documentation, get_stripe_account_info, create_customer, list_customers, create_product, list_products, create_price, list_prices, create_payment_link, create_invoice, list_invoices, create_invoice_item, finalize_invoice, retrieve_balance, create_refund, list_refunds, list_payment_intents, list_subscriptions, cancel_subscription, update_subscription, list_coupons, create_coupon, update_dispute, list_disputes, search_stripe_resources, fetch_stripe_resources, stripe_integration_recommender, send_stripe_mcp_feedback, stripe_api_search, stripe_api_details, stripe_api_execute). MCP tool calls share state with the Stripe API and Checkout surfaces — resources created via MCP are visible through the API, dashboard, and webhooks. Requests without a Authorization: Bearer <token> header return 401 Unauthorized.

• Stripe resources start empty unless seeded or created by the app under test.
• API key validation recognizes Stripe-style key prefixes and simulates authentication behavior; no real Stripe account is contacted.
• The twin models the API resources listed above; newer or specialized Stripe products outside that surface may be absent or approximated.

​

Waterfall

• Waterfall API workflows for company search, people search, enrichment, verification, and account endpoints.
• API-key authentication with UUID-shaped keys such as ad18e456-0dd7-45e1-b094-43a0361aedfa.
• Environment-variable rewrites through the wizard for WATERFALL_API_KEY, WATERFALL_API_BASE_URL, WATERFALL_API_URL, and WATERFALL_BASE_URL.

• Waterfall data starts empty unless seeded or created through API calls.
• The twin focuses on API-compatible enrichment and verification workflows; broader Waterfall dashboard behavior is outside the primary fidelity target.
• The Waterfall twin is backend-only; there is no browsable UI surface in the Arga app.

​

Unified

• Unified.to integration, auth, connection, webhook, and passthrough-style flows for apps that call Unified instead of a provider API directly.
• Seeded provider connections for Slack, Google Mail, Google Drive, Google Calendar, Box, Notion, and Dropbox.
• Unified calendar, messaging, HRIS, storage, KMS/page, comment, and event routes over deterministic in-memory provider state.

• Use provider-specific twins when your app talks directly to Slack, Dropbox, Google Drive, Google Calendar, Box, Notion, or another upstream provider.
• The Unified twin models generic Unified behavior and selected provider bridges; it is not a replacement for every provider-specific API edge case.
• Missing connections or provider records return structured 404 or 400 errors.

​

Unstructured

• Legacy partition endpoint at POST /general/v0/general.
• Workflow API routes for sources, destinations, connection checks, workflows, jobs, job cancellation, job details, failed files, job downloads, templates, and deterministic async job lifecycles.
• API-key authentication, scope families, document validation, event producers, webhook subscriptions, signed delivery attempts, retries, replay, failure injection, and admin inspection.

• Unsupported file extensions, encrypted files, invalid PDFs, retired VLM models, unsupported VLM provider/model pairs, and invalid auth scopes return structured errors.
• On-demand jobs enforce modeled constraints such as file count, file size, launch spacing, and concurrent active job limits.
• Some output-format behavior is approximated; unsupported output formats fall back to JSON unless callers request CSV explicitly.