> ## 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. # Twin reference > Per-twin support, known limitations, and MCP tools 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: | Tool | Use it for | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `get_twin_catalog` | List provisionable twin names and their kinds. | | `provision_twins` | Start an ephemeral twin environment. Pass the twin name in the comma-separated `twins` parameter. | | `start_url_validation` | Start a validation run with twins attached. Pass the twin name in the comma-separated `twins` parameter. | | `get_validation_results` | Poll validation and provisioning run status. Validation runs return structured terminal results; twin provisions report status text such as `queued`, `provisioning`, `ready`, or `failed`. | For full parameters, see [MCP](/mcp#available-mcp-tools). ## Twin links | Twin | Kind | Reference | | ----------------- | ------- | ----------------------------------- | | `box` | Backend | [Box](#box) | | `discord` | UI | [Discord](#discord) | | `dropbox` | UI | [Dropbox](#dropbox) | | `github` | UI | [GitHub](#github) | | `gitlab` | UI | [GitLab](#gitlab) | | `gmail` | UI | [Gmail](#gmail) | | `google_calendar` | UI | [Google Calendar](#google-calendar) | | `google_drive` | UI | [Google Drive](#google-drive) | | `jira` | Backend | [Jira](#jira) | | `notion` | UI | [Notion](#notion) | | `salesforce` | Backend | [Salesforce](#salesforce) | | `slack` | UI | [Slack](#slack) | | `stripe` | UI | [Stripe](#stripe) | | `waterfall` | Backend | [Waterfall](#waterfall) | | `unified` | Backend | [Unified](#unified) | | `unstructured` | Backend | [Unstructured](#unstructured) | ## 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](https://docs.github.com/apps/creating-github-apps/setting-up-a-github-app/creating-a-github-app-from-a-manifest) 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](https://github.com/github/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/stub-hits` and cleared with `POST /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 ` 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`.