Twin reference

Use this page to pick the right twin name for CLI, API, and MCP workflows. This catalog reflects the twins the current Arga app exposes for provisioning and URL validation.

​

MCP tools

All twins on this page can be discovered and used through the Arga MCP server: For full parameters, see MCP.

​

Twin links

​

Box

Twin name: box Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Discord

Twin name: discord Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Dropbox

Twin name: dropbox Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

GitHub

Twin name: github Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

GitLab

Twin name: gitlab Supports

• 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.

Known limitations

• 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 process or sandbox closes.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Gmail

Twin name: gmail Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Google Calendar

Twin name: google_calendar Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Google Drive

Twin name: google_drive Supports

• 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.
• Google API client compatibility through a Drive discovery document.
• OAuth scope enforcement, change polling, watch notifications, deterministic retries, replay, and storage tier-based quotas.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Jira

Twin name: jira Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Notion

Twin name: notion Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Salesforce

Twin name: salesforce Supports

• Salesforce Platform REST API discovery (GET /services/data, GET /services/data/v{version}, and GET /services/data/v{version}/limits).
• sObject CRUD for standard objects (Account, Contact, Case, EmailTemplate, EmailMessage, User, and related types) under /services/data/v{version}/sobjects/{sobject}, including GET, POST, PATCH, and DELETE by record ID, describe, describe/layouts, describe/compactLayouts, listviews, relationship traversal, updated/deleted feeds, and the relevantItems endpoint.
• SOQL (/services/data/v{version}/query, queryAll, and query/{locator}), SOSL (/services/data/v{version}/search, parameterizedSearch, search/scopeOrder, search/layout), composite endpoints (composite, composite/batch, composite/graph, composite/tree/{sobject}), and Bulk API v2 job shells (jobs/query, jobs/ingest).
• Invocable actions (actions, actions/standard, actions/custom) including the standard email and case-creation actions used by support workflows, plus Tooling API surface for sobjects, queries, and basic discovery.
• OAuth 2.0 token exchange at /services/oauth2/token (and /oauth2/token), userinfo at /services/oauth2/userinfo, identity URLs at /id/{org_id}/{user_id}, and bearer-token authentication.
• Admin endpoints for deterministic seeding (POST /admin/reset, GET /admin/state, POST /admin/clock) and a liveness check at GET /healthz (also GET /health).

Known limitations

• Accounts, contacts, cases, email templates, email messages, and users start empty unless seeded through config or scenario seeding, or created through API calls.
• The fidelity target is the Salesforce REST API surface needed for CRUD, query/search, composite requests, limits/recent/actions discovery, and support-style case and email-template flows; products and endpoints outside that set (for example, Apex REST, Streaming API, Metadata API, and Einstein APIs) may be approximated or absent.
• Salesforce real-service fidelity checks are opt-in and only run when SALESFORCE_REAL_FIDELITY=1 is set with valid SALESFORCE_INSTANCE_URL and SALESFORCE_ACCESS_TOKEN credentials.
• The Salesforce twin is backend-only — there is no browsable UI surface in the Arga app.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Linear

Twin name: linear Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Slack

Twin name: slack Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Stripe

Twin name: stripe Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Waterfall

Twin name: waterfall Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Unified

Twin name: unified Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.

​

Unstructured

Twin name: unstructured Supports

• 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.

Known limitations

• 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.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results.