Twin reference

Documentation Index

Fetch the complete documentation index at: https://docs.argalabs.com/llms.txt

Use this file to discover all available pages before exploring further.

Use this page to pick the right twin name for CLI, API, and MCP workflows. Each twin can be provisioned directly, attached to a URL validation run, or pinned to a saved scenario environment.

​

MCP tools

All twins on this page use the same Arga MCP tools: 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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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.
• 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, and the scenario twin environment tools listed above.

​

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, pipelines, jobs, and project hooks.
• glab api style REST and GraphQL workflows, including a minimal GraphQL surface for glab api graphql calls.
• 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, and the MCP JSON-RPC tools listed above are the fidelity target; other GitLab surfaces may be approximated or absent.
• 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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

Linear

Twin name: linear Supports

• Linear GraphQL API (POST /graphql) covering queries and mutations for teams, projects, cycles, issues, labels, comments, workflow states, users, organization, and webhooks.
• Authentication with both personal API keys (raw value in the Authorization header, no Bearer prefix) and OAuth 2.0 access tokens (Authorization: Bearer <token>).
• OAuth 2.0 consent and token flows (GET/POST /oauth/authorize, POST /oauth/token, POST /oauth/revoke), scope enforcement, refresh tokens, and revocation.
• @linear/sdk compatibility: __typename is returned on every entity, relations are emitted as { id } in default selections, and error envelopes expose extensions.type values the SDK dispatches on (for example, "authentication error", "invalid input", "ratelimited", "feature not accessible").
• Webhook subscriptions with signed deliveries (Linear-Signature, Linear-Delivery, Linear-Event, and Linear-Timestamp headers), an event outbox, manual flush and replay, and delivery history.
• Admin endpoints to inspect and reseed state (/admin/state, /admin/config, /admin/reset, /admin/clock/advance, /admin/webhooks, /admin/webhook-events, /admin/webhook-deliveries, /admin/fidelity).
• Liveness check at GET /healthz and a lightweight HTML index at GET / for visual validation.

Known limitations

• Teams, projects, cycles, issues, labels, comments, tokens, and webhooks start empty unless seeded through config or scenario seeding, or created via API calls.
• The fidelity target is the GraphQL surface and @linear/sdk wire behavior; non-GraphQL or undocumented endpoints are not modeled.
• Rate limits, failure injection, and pagination are deterministic and inspectable, which is useful for testing but is not identical to every production timing detail.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results, and the scenario twin environment tools listed above.

​

LinkedIn

Twin name: linkedin Supports

• LinkedIn OAuth 2.0 authorization code grant, access token exchange, token introspection, OpenID Connect metadata, JWKS, userinfo, and ID token claims.
• Legacy /v2 profile and email endpoints, people lookup/search, first-degree connections, Share on LinkedIn posts, asset registration, and binary media uploads.
• Versioned /rest routes and SDK-style headers such as LinkedIn-Version, X-RestLi-Protocol-Version: 2.0.0, X-RestLi-Method, and query tunneling through X-HTTP-Method-Override: GET.
• Deterministic seeding for members, posts, tokens, and assets.

Known limitations

• Versioned /rest/* endpoints require both LinkedIn-Version and X-RestLi-Protocol-Version: 2.0.0; missing headers return 400 errors.
• State starts empty by default, so authenticated profile, post, and asset flows need seeded data or API-created data.
• The twin focuses on OAuth, profile, people, connection, post, and media flows rather than every LinkedIn Marketing or Ads API surface.

MCP tools: get_twin_catalog, provision_twins, start_url_validation, get_validation_results, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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.
• 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, and the scenario twin environment tools listed above.

​

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.

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.

​

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, and the scenario twin environment tools listed above.