# MetaComp Developer Docs — Full Text > Concatenated documentation for LLM ingestion. Source: https://www.metacomp.ai/developers --- # Introduction URL: https://www.metacomp.ai/developers > AI-native risk and financial infrastructure — VisionX for KYT and AgentX for accounts, payments, FX, and fixed income, usable as an Agent Skill or directly as MCP tools. MetaComp exposes its capabilities as **MCP tools** so AI agents can use them directly — **VisionX** for KYT and Web3 risk screening, and **AgentX** for account access, deposits, withdrawals, FX conversion, and fixed income workflows. ## Two ways to use MetaComp } title="Use the Agent Skill (recommended)" href="/developers/skill" description="Install the skill and talk to Claude in natural language — guided workflows, confirmations, no code." /> } title="Build with the MCP tools" href="/developers/getting-started/quickstart" description="Connect the MCP server and call the tools directly from your own agent or code." /> ## Products } title="VisionX" href="/developers/vision-x" description="KYT and Web3 risk screening for Bitcoin, Ethereum, and Tron — screen wallets and transactions." /> } title="AgentX" href="/developers/financial-services" description="Payments and fixed income — deposit, withdraw, exchange, and invest via 32 MCP tools." /> ## Get started } title="Quickstart" href="/developers/getting-started/quickstart" description="From zero to your first result in minutes — via the skill or the MCP tools." /> } title="Core Concepts" href="/developers/getting-started/core-concepts" description="MCP, the products, and how it all fits together." /> --- # Claude.ai URL: https://www.metacomp.ai/developers/getting-started/ai-clients/claude-ai > Connect MetaComp's MCP server to Claude.ai via the Connectors settings panel. Claude.ai connects to MetaComp over the hosted MCP server using OAuth 2.0 + PKCE. You do not need to install anything locally — just add the connector URL and authorize once. **Requirement:** Claude Pro, Team, or Enterprise subscription. ## Setup **1. Open the Connectors panel** In Claude.ai, go to **Settings → Connectors → Add custom connector**. **2. Enter the MCP URL** ``` https://www.metacomp.ai/mcp ``` **3. Authorize** Claude will redirect you to the MetaComp OAuth consent page. Paste your MetaComp API key (`sk-…`) and click **Allow**. You will be redirected back to Claude automatically. That's it. The MetaComp tools (`VisionX`, plus the AgentX tools your account's permissions allow) are now available in all your Claude.ai conversations. ## Usage You do not need to invoke tools by name. Ask naturally: - "Is this wallet address safe? `0xAbCd…1234`" - "Check this transaction: `0xDeFg…`" - "What's my current account balance?" Claude will call the appropriate tool and return a structured result. ## Notes - **Token refresh** is handled automatically by Claude. Your session stays active for up to 30 days before re-authorization is needed. - **Agent Skill** — the connector alone works, but for the best experience we recommend also installing the [MetaComp Agent Skill](/developers/skill), which adds guided natural-language workflows on top of the tools. - **Auth details:** see [Authentication — Hosted MCP (OAuth 2.0 + PKCE)](/developers/getting-started/authentication#hosted-mcp-oauth-20--pkce). --- # Claude Code URL: https://www.metacomp.ai/developers/getting-started/ai-clients/claude-code > Add MetaComp as an MCP server in Claude Code for terminal-based AI workflows. Claude Code connects to the hosted MetaComp MCP server using a Bearer token passed directly in the `Authorization` header. There is no OAuth flow — you provide your API key once on the command line. ## Setup Run this command in your terminal, replacing `YOUR_API_KEY` with your MetaComp API key (`sk-…`): ```bash claude mcp add --transport http metacomp \ https://www.metacomp.ai/mcp \ --header "Authorization: Bearer YOUR_API_KEY" ``` This registers MetaComp as an MCP server named `metacomp`. The tools are available immediately in any new Claude Code session. To verify the server was added: ```bash claude mcp list ``` You should see `metacomp` listed with the URL `https://www.metacomp.ai/mcp`. ## Recommended: the MetaComp Agent Skill For the best experience, also install the **[MetaComp Agent Skill](/developers/skill)** — one skill that adds guided, confirm-before-acting workflows across all five capability groups (KYT, deposit, withdraw, exchange, and wealth), so you don't compose tool calls manually. Download it from [github.com/metacomp-ai/metacomp-skill](https://github.com/metacomp-ai/metacomp-skill) and place it under `~/.claude/skills/`. See [Install & Connect](/developers/skill/install) for the full walkthrough. ## Usage In a Claude Code session, ask naturally: ``` Is 0xAbCd…1234 safe to send ETH to? ``` Claude will call the `VisionX` tool and return a risk report. You can also call tools directly in agent scripts or automated pipelines. ## Notes - **Auth:** Claude Code uses a direct Bearer token, not OAuth. There is no token expiry — the key is valid until revoked from the dashboard. - **Removing the server:** `claude mcp remove metacomp` - **Auth details:** see [Authentication — Local / npm MCP](/developers/getting-started/authentication#local--npm-mcp---token). --- # Claude Desktop URL: https://www.metacomp.ai/developers/getting-started/ai-clients/claude-desktop > Configure MetaComp as a local MCP server in Claude Desktop using the npm package. Claude Desktop runs MCP servers as local processes via stdio. MetaComp provides an npm package that Claude Desktop launches automatically on startup — no hosted connection or OAuth flow is required. ## Setup Locate and open your Claude Desktop configuration file: - **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json` - **Windows:** `%APPDATA%\Claude\claude_desktop_config.json` Add the following entry under `mcpServers`, replacing `YOUR_API_KEY` with your MetaComp API key (`sk-…`): ```json { "mcpServers": { "metacomp": { "command": "npx", "args": ["-y", "--package", "@metacomp/visionx-kyt-mcp", "visionx-kyt-mcp", "--token", "YOUR_API_KEY"] } } } ``` Save the file and **restart Claude Desktop**. The MetaComp tools will appear in the tool panel. ## Usage Once connected, ask naturally in any conversation: - "Is this wallet safe to send funds to? `0xAbCd…1234`" - "Check this transaction for risk: `0xDeFg…`" Claude Desktop will invoke the appropriate MCP tool and return the result inline. ## Notes - **Auth:** The `--token` flag passes your API key directly to the local npm process. There is no OAuth flow or token expiry — the key is valid until revoked. - **Package source:** The npm package is `@metacomp/visionx-kyt-mcp`. npx downloads and caches it automatically. - **Legacy path.** The npm package `@metacomp/visionx-kyt-mcp` is a **separate legacy server** that runs on your machine and reaches deprecated backend endpoints. It exposes two older VisionX tools — `get_wallet_security` and `get_transaction_security` — rather than the hosted server's single `VisionX` tool, and it covers VisionX only (no AgentX tools). New integrations should use the hosted server. - **Auth details:** see [Authentication — Local / npm MCP](/developers/getting-started/authentication#local--npm-mcp---token). --- # Cursor, Windsurf & Cline URL: https://www.metacomp.ai/developers/getting-started/ai-clients/cursor-windsurf-cline > Set up MetaComp's MCP server in editor-based AI clients such as Cursor, Windsurf, and Cline. Cursor, Windsurf, and Cline all support MCP servers via URL. They connect to MetaComp using the hosted server and authenticate via OAuth 2.0 + PKCE — the same flow as Claude.ai. ## Setup **1. Add the MCP server** In your client's MCP or tools settings panel, add a new MCP server with the URL: ``` https://www.metacomp.ai/mcp ``` The exact location varies by client: - **Cursor:** Settings → Tools & Integrations → MCP Servers → Add - **Windsurf:** Settings → MCP → Add Server - **Cline:** Extension settings → MCP Servers → Add **2. Authorize** After adding the URL, the client will initiate the OAuth flow. You will be redirected to the MetaComp consent page — paste your MetaComp API key (`sk-…`) and click **Allow**. **3. Add SKILL.md to your system prompt (recommended)** For the best results, paste the contents of `SKILL.md` from the [metacomp-skill](https://github.com/metacomp-ai/metacomp-skill) repository into your client's system prompt or custom instructions field. This gives the AI model structured guidance on when and how to invoke MetaComp tools. - **Cursor:** Settings → Rules for AI → paste SKILL.md content - **Windsurf:** Settings → Custom Instructions → paste SKILL.md content - **Cline:** Extension settings → Custom Instructions → paste SKILL.md content ## Usage Once connected, mention a wallet address or transaction hash in your editor conversation: ``` Is 0xAbCd…1234 safe to receive payment from? ``` The client will call the `VisionX` tool and return the result inline. You can also use MetaComp tools inside agent workflows and automated tasks. ## Notes - **Auth:** These clients use OAuth 2.0 + PKCE against the hosted MCP server. Token refresh is handled automatically. - **No local install required:** The hosted MCP server runs on MetaComp's infrastructure — nothing to install locally. - **Auth details:** see [Authentication — Hosted MCP (OAuth 2.0 + PKCE)](/developers/getting-started/authentication#hosted-mcp-oauth-20--pkce). --- # Overview URL: https://www.metacomp.ai/developers/getting-started/ai-clients > Compare the supported AI clients and choose the right integration path for your workflow. MetaComp's MCP server works with any MCP-compatible AI client. This section provides a setup guide for each supported client and a capability matrix to help you choose the right path. ## Capability matrix | Client | MCP transport | Auth | Notes | |---|---|---|---| | [Claude.ai](/developers/getting-started/ai-clients/claude-ai) | Streamable HTTP (hosted) | OAuth 2.0 + PKCE | Best conversational experience; requires Claude Pro, Team, or Enterprise | | [Claude Code](/developers/getting-started/ai-clients/claude-code) | Streamable HTTP (hosted) | Bearer token (header) | Best for developer and agent workflows; terminal-based | | [Claude Desktop](/developers/getting-started/ai-clients/claude-desktop) | Local npm package (stdio) | `--token` flag | Runs MCP server locally; no hosted connection | | [VS Code](/developers/getting-started/ai-clients/vs-code) | Streamable HTTP (hosted) | Bearer token (`mcp.json` headers) | Best for editor-based development workflows; supports workspace and user-level MCP config | | [Cursor / Windsurf / Cline](/developers/getting-started/ai-clients/cursor-windsurf-cline) | Streamable HTTP (hosted) | OAuth 2.0 + PKCE | Editor-integrated; add SKILL.md to system prompt for best results | All clients connect to the same MCP server and have access to the same tools. The differences are in how they authenticate and how context is loaded. For details on the two auth paths, see [Authentication](/developers/getting-started/authentication). --- # VS Code URL: https://www.metacomp.ai/developers/getting-started/ai-clients/vs-code > Connect MetaComp's MCP server to Visual Studio Code by configuring a remote HTTP MCP server in mcp.json. VS Code can connect to MetaComp as a remote HTTP MCP server. This is a good fit for editor-based workflows where you want MetaComp's tools available in GitHub Copilot Chat and agent tasks without leaving your workspace. ## Setup Use either of these configuration scopes: - **Workspace** — create `.vscode/mcp.json` in your project to share the MCP server setup with the team. - **User profile** — use the Command Palette and run **MCP: Open User Configuration** to configure MetaComp once for all workspaces. Add the following configuration, replacing the input prompt label if you want: ```json { "inputs": [ { "type": "promptString", "id": "metacomp-api-key", "description": "MetaComp API key", "password": true } ], "servers": { "metacomp": { "type": "http", "url": "https://www.metacomp.ai/mcp", "headers": { "Authorization": "Bearer ${input:metacomp-api-key}" } } } } ``` When VS Code starts the server for the first time, it prompts you for the API key and stores it securely for reuse. ## Usage Open Chat in VS Code and ask naturally: ```text Is 0xAbCd…1234 safe to receive USDT from? ``` VS Code can then call the MetaComp MCP tools directly from chat or agent-driven workflows. ## Notes - **Auth:** For MetaComp, the simplest VS Code setup is a direct Bearer token in the `headers` field of `mcp.json`. - **No local install required:** VS Code connects to the hosted MCP server at `https://www.metacomp.ai/mcp`. - **Safer secret handling:** Prefer an input variable over hardcoding the API key directly in the file. - **Manage servers:** Use **MCP: Add Server**, **MCP: List Servers**, or **MCP: Open User Configuration** from the Command Palette. - **Auth details:** see [Authentication](/developers/getting-started/authentication). --- # Authentication URL: https://www.metacomp.ai/developers/getting-started/authentication > How to obtain a MetaComp API key and understand the two authentication paths — OAuth 2.0 (hosted MCP) and direct token (local/npm MCP). MetaComp exposes a single public integration surface: an MCP server. There are two ways to authenticate against it, depending on which AI client you use. ## API keys A MetaComp API key is a secret credential that identifies a single user account. It begins with `sk-` and looks like: ``` sk-a1b2c3d4e5f6... ``` **Where to get one:** Log in to the [MetaComp dashboard](https://www.metacomp.ai/dashboard), find the **API Keys** section, and click **Generate New Key**. Copy it immediately — it is shown only once. Your API key grants full access to your MetaComp account. Never commit it to source control, paste it into shared documents, or include it in logs. Treat it like a password. One API key maps to exactly one user account. If you need to revoke access, delete the key from the **API Keys** section in the dashboard; a replacement key can be generated at any time with no downtime. ## Hosted MCP (OAuth 2.0 + PKCE) The hosted server at `https://www.metacomp.ai/mcp` is protected by **OAuth 2.0 with PKCE** and dynamic client registration. This is the standard flow used by Claude.ai and other clients that connect via URL. **From an end-user perspective, the flow is simple:** you enter the MCP URL into your client, click connect, and you are redirected to a MetaComp consent page where you paste your `sk-…` API key and click **Allow**. That's it — you never see a client ID, code verifier, or token. **What actually happens behind the scenes (for reference):** 1. Your client sends `POST /mcp` without credentials. 2. The server responds `401 Unauthorized` with a `WWW-Authenticate` header pointing to the discovery endpoints. 3. Your client fetches `/.well-known/oauth-protected-resource` and `/.well-known/oauth-authorization-server` to discover the authorization server configuration. 4. Your client registers itself via `POST /oauth/register` (dynamic client registration — no pre-registration required). 5. Your client redirects you to `GET /oauth/authorize`, where the consent UI asks for your MetaComp API key. 6. You paste your `sk-…` key and approve. The server issues an authorization code. 7. Your client exchanges the code for tokens via `POST /oauth/token`. 8. The server returns an **access token** (JWT, valid 1 hour) and a **refresh token** (valid 30 days). Your client stores and refreshes these automatically. You do not need to manage tokens or handle the OAuth flow manually. Compliant MCP clients (Claude.ai, Cursor, Windsurf, Cline) implement this flow automatically. ## Local / npm MCP (`--token`) When running MetaComp's MCP package locally via npm, authentication bypasses OAuth entirely. You pass your API key directly as a command-line flag: ```bash npx -y --package @metacomp/visionx-kyt-mcp visionx-kyt-mcp --token YOUR_API_KEY ``` The package sends the key as a `Bearer` token in the `Authorization` header on every request. There is no token expiry or refresh — the key is valid until revoked. The npm package `@metacomp/visionx-kyt-mcp` is a **separate legacy server** that runs on your machine and reaches deprecated backend endpoints. It exposes two older VisionX tools — `get_wallet_security` and `get_transaction_security` — rather than the hosted server's single `VisionX` tool, and it covers VisionX only (no AgentX tools). New integrations should use the hosted server. Claude Desktop uses this path, configured via `claude_desktop_config.json`. Claude Code also uses the direct-token path (passed via `--header`), not OAuth. VS Code can also connect this way by setting the `Authorization` header in `mcp.json`. ## Which client uses which | Client | Auth path | How you provide the key | |---|---|---| | Claude.ai | OAuth 2.0 + PKCE (hosted MCP) | Paste `sk-…` once at the OAuth consent page | | Claude Code | Direct Bearer token (header) | `--header "Authorization: Bearer YOUR_API_KEY"` on `claude mcp add` | | Claude Desktop | Direct token (`--token` flag) | `"--token", "YOUR_API_KEY"` in `claude_desktop_config.json` | | VS Code | Direct Bearer token (`mcp.json` headers) | `"Authorization": "Bearer ${input:metacomp-api-key}"` in `mcp.json` | | Cursor / Windsurf / Cline | OAuth 2.0 + PKCE (hosted MCP) | Paste `sk-…` once at the OAuth consent page | --- MCP is the primary surface for both end-users and automated agents. VisionX screening is additionally available as a direct REST endpoint for backends that integrate without an MCP client — see [VisionX — API](/developers/vision-x/api). For a conceptual overview of how MCP works and what products are available, see [Core Concepts](/developers/getting-started/core-concepts). --- # Core Concepts URL: https://www.metacomp.ai/developers/getting-started/core-concepts > The foundational ideas behind MetaComp's MCP-first architecture — what MCP is, the product lines, tool safety, and how cross-vendor aggregation works. ## MCP, in one paragraph [MCP (Model Context Protocol)](https://modelcontextprotocol.io) is a standard that lets AI clients call external tools in a structured way. When you connect MetaComp to Claude, Cursor, or any MCP-compatible client, the client gains a set of **tools** — named functions it can invoke on your behalf. MetaComp's server exposes these tools over **Streamable HTTP** at `POST https://www.metacomp.ai/mcp`. Each time the AI decides it needs to check a wallet address, look up an account balance, or place a trade, it calls the appropriate tool, gets back a structured result, and incorporates it into its response — all without you leaving the conversation. ## Products and modules MetaComp exposes two product lines via MCP: ### VisionX — Know Your Transaction (KYT) VisionX screens blockchain addresses and transactions for risk. It is available in **all environments** and is the starting point for most integrations. **MCP tools:** | Tool | What it does | |---|---| | `VisionX` | Screens a wallet address, a single transaction, or both in one call. Returns a risk level, exposure by counterparty category, transaction timeline, and a cross-vendor comparison; screening a transaction also screens its counterparty wallet | Supported networks: Bitcoin, Ethereum, Tron. ### AgentX — financial workflows AgentX is MetaComp's financial operations layer for AI agents. It gives an agent structured access to account balances, money movement, OTC FX conversion, transaction history, and wealth-product subscription flows. Its main workflows are: - **Deposit** — fiat and crypto deposit flows, including bank instructions, wallet addresses, network selection, and estimate flows. - **Withdraw** — fiat and crypto withdrawal flows, including quote checks, destination selection, verification-code handling, and execution. - **OTC exchange** — indicative rates, locked quotes, confirmation, and trade-detail lookup for FX conversion. - **Wealth** — wealth products and subscription flows, including investor eligibility, product listings, agreements, and order submission. Most AgentX flows are multi-step and stateful: the agent typically checks permissions, gathers quotes or destination details, asks for confirmation, and only then executes the final action. For a full breakdown of accounts, currencies, and the first-party vs. third-party model, see [AgentX Concepts](/developers/financial-services/concepts). ## Read-only vs. destructive tools Every MCP tool is annotated with a `readOnlyHint`. **Read-only tools** can be called freely by the AI as part of gathering information. **Destructive tools** — those that move money, submit transactions, or upload documents — carry `readOnlyHint: false` and **require explicit user confirmation** before the AI client will execute them. The destructive tools are: - `execute_fiat_withdrawal` - `execute_crypto_withdrawal` - `confirm_otc_trade` - `fip_subscribe` - `execute_third_party_fiat_deposit_submit` - `upload_file` When the AI reaches a step that calls one of these tools, it will pause and ask you to confirm before proceeding. This is enforced by the MCP protocol, not just convention. ## Cross-vendor aggregation (VisionX) A single VisionX risk check does not query just one blockchain analytics provider — it queries **multiple vendors simultaneously** (including providers such as Chainalysis, Elliptic, TRM, Merkle Science, Beosin, and SlowMist) and aggregates the results into one report. The response includes: - A **per-vendor breakdown** showing each provider's raw risk assessment - A **unified cross-vendor verdict** that reconciles disagreements across providers - **Exposure categories** (sanctions exposure, scam connections, mixer activity, darknet links) derived from the combined signal This means you get a more complete and defensible risk picture than any single-source check can provide — especially important for compliance workflows where vendor disagreements are significant. ## First-party vs. third-party (AgentX) AgentX tools operate in one of two modes depending on how funds flow: **first-party** (directly through MetaComp's own infrastructure) and **third-party** (routed via a custody partner, currently COBO). The distinction affects which currencies are supported, fee structures, and the shape of API responses. For a full explanation of this model, account types, and how minor units work, see [AgentX Concepts](/developers/financial-services/concepts). --- # Quickstart URL: https://www.metacomp.ai/developers/getting-started/quickstart > The fastest way to start with MetaComp — install the Agent Skill in Claude, or connect the MCP tools directly in your own agent. There are two ways to start. Pick the one that fits you. ## Recommended: use the Agent Skill No code. If this is your first time using MetaComp, start with the Agent Skill in Claude.ai. The fastest path is: download the skill, install it in Claude.ai, connect the MetaComp MCP server, then run a KYT check in plain language. **Download the skill package** — download the latest MetaComp skill ZIP from [GitHub Releases](https://github.com/metacomp-ai/metacomp-skill/releases/latest). Use the production package that matches `https://www.metacomp.ai`. If you need the full installation walkthrough, see [Install & Connect](/developers/skill/install). **Install the skill in Claude.ai** — in Claude.ai, open **Customize → Skills**, create a new skill, and upload the downloaded MetaComp skill ZIP. Make sure the skill is enabled after upload. **Get an API key** — log in to the [MetaComp dashboard](https://www.metacomp.ai/dashboard), locate the **API Keys** section, and click **Generate New Key**. Copy the `sk-…` key immediately — it is shown only once. **Connect the MetaComp MCP server** — in Claude.ai, open **Settings → Connectors → Add custom connector**, enter `https://www.metacomp.ai/mcp`, and authorize with your `sk-…` API key when prompted. **Run your first KYT check** — return to chat and ask a simple wallet-risk question such as: > Is `0xAbCd…1234` safe to send ETH to? Claude will load the MetaComp skill, call the VisionX toolchain, and return a KYT result with risk signals and supporting context. **Check your MetaComp account balance** — once the KYT check works, try a simple account-level prompt such as: > Show my MetaComp account balance. If your MetaComp account is not logged in yet, Claude.ai will give you a login link. Follow Claude.ai's instructions, click the link, complete the MetaComp login flow, then return to Claude.ai and continue the request. After login succeeds, Claude will call the account tools and show your current balance summary. This is a good second step because it confirms your MCP connection and your MetaComp account session are both working. → Full guide: [Agent Skill](/developers/skill). ## Building your own agent? Use the MCP server directly Integrating MetaComp into your own agent or workflow? Skip the skill and connect to the MetaComp MCP server directly. Then choose the product area you need: - [VisionX tools](/developers/vision-x/tools) — screen wallets and transactions for on-chain risk. - [AgentX tools](/developers/financial-services/tools) — query accounts, move money, exchange currencies, and subscribe to FIP products. - [AI Clients](/developers/getting-started/ai-clients) — setup guides for Claude, VS Code, and other MCP-capable clients. **Get an API key** — create one from the **API Keys** section of the [MetaComp dashboard](https://www.metacomp.ai/dashboard) and copy the `sk-…` value when it is shown. **Connect the MCP server** — for Claude Code: ```bash claude mcp add --transport http metacomp \ https://www.metacomp.ai/mcp \ --header "Authorization: Bearer YOUR_API_KEY" ``` For VS Code and other clients, see [AI Clients](/developers/getting-started/ai-clients). **Run your first call** — ask *"Is `0xAbCd…1234` safe to send ETH to?"* and Claude calls the `VisionX` tool, returning a risk level, exposure categories, transaction timeline, and a cross-vendor verdict. Paste a transaction hash and the same tool screens the transaction plus its counterparty wallet. ## Next steps - [Core Concepts](/developers/getting-started/core-concepts) — MCP, the products, and read-only vs. destructive tools. - [VisionX](/developers/vision-x) — KYT concepts, guides, tools, and response shapes. - [AgentX](/developers/financial-services) — accounts, payments, exchange, wealth, and shared execution prerequisites. --- # How It Works URL: https://www.metacomp.ai/developers/skill/how-it-works > How the MetaComp Agent Skill relates to the MCP server and to your MetaComp account. Three layers cooperate when you use the skill. Understanding them clarifies what lives where — and why the skill alone isn't enough without the MCP connection and an account. ## The three layers ### 1. The skill — the agent playbook The skill is a set of instructions (a `SKILL.md` entry point plus progressively-loaded sub-skills) that tells Claude **how** to handle each request: which steps to run, what to confirm, and how to present results. It holds **no secrets** and makes **no network calls** itself — it only directs Claude. This is why it can be open-source and shipped as plain files. ### 2. The MCP server — the tools The actual operations live on the **MetaComp MCP server** at `https://www.metacomp.ai/mcp`, which exposes them as [MCP tools](/developers/vision-x/tools) (for example `VisionX`, `get_account_summary`, `execute_fiat_withdrawal`). When the skill decides an action is needed, Claude calls the matching tool over the MCP connection. MCP is the surface the skill uses; VisionX screening is also reachable as a direct [REST endpoint](/developers/vision-x/api), which the skill does not use. ### 3. Your MetaComp account — the system of record Your `sk-…` API key authenticates the MCP connection to **your MetaComp account**. Balances, KYC / eligibility status, deposits, withdrawals, and fixed-income holdings all live on that account. The skill and the MCP server are just the interface; your account is where the money and identity actually are. ## The flow ``` You (natural language) → Claude + Skill decides the workflow & what to confirm → MCP tools execute the operation over /mcp → MetaComp account the system of record (balances, KYC, orders) → results rendered back to you as prose / tables ``` ## Read-only vs. destructive The skill enforces the same safety model as the tools themselves: - **Read-only** actions — KYT screening, balance and history queries — run without interruption. - **Destructive** actions — withdrawals, exchange confirmation, FIP subscription — always pause for your explicit confirmation and are never silently retried. See [Core Concepts](/developers/getting-started/core-concepts) and [Status & Errors](/developers/reference/status-and-errors) for the underlying behavior. If your session expires, tools return a re-authentication link and the skill stops and shows it to you rather than failing silently. --- # Overview URL: https://www.metacomp.ai/developers/skill > The MetaComp Agent Skill packages MetaComp as an agent skill layer on top of the MCP server — one skill, five capability groups, driven by natural language. The **MetaComp Agent Skill** turns MetaComp into a guided natural-language experience inside AI clients. It is a single [Agent Skill package](https://github.com/metacomp-ai/metacomp-skill) that sits on top of the MetaComp MCP server: instead of composing tool calls yourself, you load the skill and just ask — your agent follows the right multi-step workflow, confirms before anything moves money, and returns clean, readable results. It is **one skill** that provides **five capability groups**: } title="Web3 Security (KYT)" href="/developers/vision-x" description="Screen any wallet or transaction for risk via VisionX." /> } title="Deposit" href="/developers/financial-services/guides/deposit-fiat" description="Receive fiat or crypto into your MetaComp account." /> } title="Withdraw" href="/developers/financial-services/guides/withdraw-fiat" description="Send fiat or crypto — first-party or third-party." /> } title="Exchange" href="/developers/financial-services/guides/exchange-otc" description="OTC currency exchange with a locked quote." /> } title="Wealth" href="/developers/financial-services/guides/wealth-fip" description="Subscribe to Fixed Income Products (FIP)." /> ## Why use the skill The MCP server already exposes every MetaComp operation as a [tool](/developers/vision-x/tools). The skill is the **agent playbook** on top of it — so you get: - **Guided workflows** — multi-step flows (quote → confirm → execute, precheck → subscribe) are orchestrated for you; no manual tool composition. - **Safe by default** — destructive actions (withdrawals, exchange confirmation, FIP subscription) always pause for your explicit confirmation. - **Clean output** — results come back as readable prose and tables, never raw JSON. - **Natural and multilingual** — ask in plain language; the skill matches the language you use. ## Next steps - [Install the skill](/developers/skill/install) — load it into your AI client and connect your account. - [How it works](/developers/skill/how-it-works) — the skill, the MCP server, and your MetaComp account. --- # Install & Connect URL: https://www.metacomp.ai/developers/skill/install > Install the MetaComp Agent Skill in Claude.ai (recommended) or another agent, and connect it to your MetaComp account via the MCP server. The skill is distributed from **[github.com/metacomp-ai/metacomp-skill](https://github.com/metacomp-ai/metacomp-skill)**. Every setup has the same two parts: 1. **Load the skill** into your agent (the playbook that tells Claude *how* to work). 2. **Connect the MetaComp MCP server** with your API key (the tools that actually *do* the work). The skill alone does nothing without the MCP connection — and the MCP alone works but without the guided workflows. You need both. See [How it works](/developers/skill/how-it-works). ## Prerequisites - A **MetaComp account** and an API key (`sk-…`) — create it from the **API Keys** section of the [MetaComp dashboard](https://www.metacomp.ai/dashboard). See [Authentication](/developers/getting-started/authentication). - The skill package — download the latest skill ZIP from the repository's [Releases](https://github.com/metacomp-ai/metacomp-skill/releases/latest) and unzip it. Use the production package for `https://www.metacomp.ai`. --- ## Claude.ai (recommended) Claude.ai is the best place to use the skill — it has first-class Skills support and the cleanest experience. **Check that skills are enabled** — Skills require **Code execution and file creation** to be enabled first. - **Free / Pro / Max:** open **Settings → Capabilities** and make sure **"Code execution and file creation"** is on. - **Team / Enterprise users:** this capability is typically managed by your organization. If skills are unavailable, ask your organization owner to confirm **"Code execution and file creation"** is enabled in **Organization settings → Capabilities**. - **Team / Enterprise owners provisioning skills org-wide:** enable both **"Code execution and file creation"** and **"Skills"** in **Organization settings → Skills**. **Download the skill package** — download the latest MetaComp skill ZIP from the repository's [Releases](https://github.com/metacomp-ai/metacomp-skill/releases/latest). Use the production package that matches `https://www.metacomp.ai`, then keep the ZIP ready for upload. **Upload the skill** — open **Customize → Skills**, click **"+" → "+ Create skill" → "Upload a skill"**, and choose the skill **ZIP**. The ZIP must contain the **skill folder at its root** (not nested in a subfolder). Make sure the skill's toggle is **on**. **Connect the MetaComp MCP server** — open **Settings → Connectors → Add custom connector**, enter the MCP URL `https://www.metacomp.ai/mcp`, and authorize with your `sk-…` API key. Custom connectors require Claude **Pro, Team, or Enterprise**. Full walkthrough: [Claude.ai client setup](/developers/getting-started/ai-clients/claude-ai). **Ask** — start a chat and ask naturally; the skill triggers on intent (see [examples](#example-prompts) below). --- ## Claude Code Claude Code loads skills from directories. The MetaComp skill is distributed as a single ZIP package; when you unzip it, you get one skill folder with a `SKILL.md` entry point plus supporting files such as `subSkills/` and references. **Place the skill folder** — download the MetaComp skill ZIP from [Releases](https://github.com/metacomp-ai/metacomp-skill/releases/latest), then unzip it so the resulting skill folder sits one level under a Claude skills directory: - **Personal** (all projects): `~/.claude/skills//...` - **Project** (this repo only): `.claude/skills//...` ```bash mkdir -p ~/.claude/skills unzip metacomp-skill.zip -d ~/.claude/skills/ # result: # ~/.claude/skills//SKILL.md # ~/.claude/skills//subSkills/... # ~/.claude/skills//references/... ``` Keep the unzipped skill folder intact so Claude Code can load both `SKILL.md` and its supporting files. Edits to an existing skills directory are picked up within the session; creating `~/.claude/skills/` for the first time needs a Claude Code restart. **Connect the MetaComp MCP server:** ```bash claude mcp add --transport http metacomp \ https://www.metacomp.ai/mcp \ --header "Authorization: Bearer YOUR_API_KEY" ``` **Use it** — Claude loads the skill automatically when your request matches, or invoke it directly with `/`. --- ## VS Code, Cursor, Windsurf & Cline These editor-based clients support **MCP** but do not natively load Anthropic Agent Skills. Use them in two steps: **Add the MetaComp MCP server** — URL `https://www.metacomp.ai/mcp`, authorized with your `sk-…` key. See [VS Code](/developers/getting-started/ai-clients/vs-code) or [Cursor / Windsurf / Cline](/developers/getting-started/ai-clients/cursor-windsurf-cline) setup. **Add the playbook as rules** — paste the contents of the skill's `SKILL.md` into the client's rules, custom instructions, agent customization, or system prompt, so the agent follows the same guided workflows. You get the same MetaComp tools either way; pasting the skill instructions reproduces the guided, confirm-before-acting behavior. --- ## Other agents & the API Agent Skills follow the open **[Agent Skills](https://agentskills.io)** standard, so any agent that adopts it can load the `SKILL.md` package the same way. To build your own agent programmatically, use the skill with the Claude API / Agent SDK — see the [Claude API skills guide](https://docs.claude.com/en/api/skills-guide). In all cases the skill still needs the MetaComp MCP server (`https://www.metacomp.ai/mcp`) connected with your API key. --- ## Example prompts Once the skill is loaded and the MCP server is connected, ask naturally: > Is `0xAbCd…1234` safe to send ETH to? > I want to exchange 10,000 USDT to SGD. > Show my account balance and recent withdrawals. > Subscribe 5,000 USDC to a 30-day fixed income product. Claude routes each request to the matching capability, walks the flow, and confirms with you before anything moves money. --- # API URL: https://www.metacomp.ai/developers/vision-x/api > Screen wallets and transactions for AML risk with a single REST call — POST /api/v1/transAndWallet. **One call, combined screening.** `POST /api/v1/transAndWallet` runs a transaction risk screen and a counterparty wallet screen in parallel and returns both results. It is the direct-integration alternative to the `VisionX` MCP tool — the same KYT screening, callable from any backend or service over plain HTTPS, no MCP client required. This endpoint only needs an API key — no MetaComp account session is required. Base URL: `https://www.metacomp.ai` ## Authentication Pass your API key (`sk-…`, created in the [MetaComp dashboard](https://www.metacomp.ai/dashboard)) on every request, either as a bearer token or an `X-API-Key` header: ```bash Authorization: Bearer sk-your-key # or X-API-Key: sk-your-key ``` See [Authentication](/developers/getting-started/authentication) for how to create and manage keys. ## Request `POST /api/v1/transAndWallet` — `Content-Type: application/json` | Field | Type | Required | Description | |---|---|---|---| | `network` | string | Yes | Supported networks: `Bitcoin`, `Ethereum`, `Tron`. Send the value exactly as written here — the same set the [MCP tool](/developers/vision-x/tools) accepts. | | `channel` | string | Yes | Caller channel. Fixed value — always send `"api"`. | | `walletAddress` | string | One of | Wallet address to screen. Passed through as sent; addresses are not normalized or checksummed for you. | | `transactionDetail` | object | One of | A single transaction to screen — one object, not an array. | At least one of `walletAddress` or `transactionDetail` must be provided. `transactionDetail` (all fields required): | Field | Type | Description | |---|---|---| | `hash` | string | Transaction hash. Together with `network` this is what identifies the transaction. | | `asset` | string | Asset symbol as it appears in the transfer, e.g. `USDT`, `ETH`. Screening context only — it is **not** used to identify the transaction, so a symbol that exists on several chains or contracts (e.g. `USDT`) needs no disambiguation here. | | `direction` | string | `received` or `sent`, relative to your side of the transfer. Determines which counterparty gets wallet-screened. Any other value is rejected with 400. | | `from` | string | Sender address. | | `to` | string | Recipient address. | One call screens **one** transaction. Batching is not supported: send an array and the request is rejected with 400. To screen several transactions, call once per transaction — each call is billed separately and screens that transaction's counterparty wallet. ## Behavior Which wallet gets screened depends on what you send: | You send | Transaction screen | Wallet screen target | |---|---|---| | Only `walletAddress` | Skipped — `transactionCheck` is `null` | `walletAddress` itself | | Only `transactionDetail` | The transaction | Its **counterparty**: `direction: "received"` → `from`; `direction: "sent"` → `to` | | Both | The transaction | Same as above — `walletAddress` is ignored | Both screens run in parallel, and one call is billed as a single combined screen. **There is no partial success.** A `200` means both screens completed; if either screen fails, the whole call fails with the corresponding error status and the charge is refunded — you never receive a response where one screen succeeded and the other did not. (`transactionCheck: null` is not a failure: it means you sent no `transactionDetail`.) ## Response `200` returns one object per screen. `transactionCheck` is `null` when you sent no `transactionDetail`; otherwise both are populated. Each object is the standard screening wrapper documented in the [Response Reference](/developers/vision-x/responses) — the same wrapper and report body the MCP tool returns. Wallet-only call (values below are illustrative): ```json { "transactionCheck": null, "walletCheck": { "success": true, "code": 0, "data": { "type": "wallet", "network": "Ethereum", "address": "0x1111111111111111111111111111111111111111", "level": "High", "createTime": "2026-07-31 10:45:08", "extra": { "progress": 100, "totalIncoming": 2925569.41, "totalOutgoing": 3371497.04, "walletBalance": 0, "earliestTransactionTime": "12 Sep 2023", "latestTransactionTime": "31 Jul 2026", "directIncoming": [ { "tagTypeVerbose": "Service", "isHighRisk": false, "totalValueUsd": 787250.62, "totalValueUsdRatio": 26.91 }, { "tagTypeVerbose": "Malware", "isHighRisk": true, "totalValueUsd": 485.56, "totalValueUsdRatio": 0.02 } ], "incomingDirectExposure": [ { "tagTypeVerbose": "Malware", "isHighRisk": true, "totalValueUsd": 485.56, "totalValueUsdRatio": 0.02 } ], "incomingRiskExposureBreakdown": { "totalAmount": 2925569.41, "lowRiskAmount": 2924223.86, "highRiskAmount": 1345.55 }, "highRiskCategories": ["Sanctions", "Scams", "Theft", "Malware", "Coin Mixer", "Darknet", "Gambling", "Extortion", "High Risk Organisation"], "vendor1": { "totalIncoming": 883.74, "incomingDirectExposure": [ { "tagTypeVerbose": "Malware", "isHighRisk": true, "totalValueUsd": 485.56, "totalValueUsdRatio": 54.94 } ], "platformWalletAlert": { "hasAlert": true, "hasDirectAlert": true, "hasSevereDirectAlert": null } }, "vendor2": { "totalIncoming": 1526524.42, "incomingDirectExposure": [] }, "vendor3": { "totalIncoming": 1657970.96, "incomingDirectExposure": [] } } } } } ``` The outgoing counterparts (`directOutgoing`, `outgoingDirectExposure`, `outgoingRiskExposureBreakdown`, …), the indirect breakdowns, and the full per-provider blocks are elided above for brevity — all of them are listed field by field in the [Response Reference](/developers/vision-x/responses#wallet-report-extra). When you send `transactionDetail`, `transactionCheck` carries a transaction report (`data.type: "transaction"`) whose per-transaction verdicts sit in `extra.selectedTx[]`, and `walletCheck` carries the counterparty's wallet report. Both are documented in the same reference. ### Making decisions from the result | To decide… | Read | |---|---| | Overall wallet verdict | `walletCheck.data.level` | | Per-transaction verdict | `transactionCheck.data.extra.selectedTx[].txRiskLevel` | | Whether high-risk counterparties are involved | the `*Exposure` arrays, or `isHighRisk` on the breakdown entries | | How much value is tainted | `incoming` / `outgoingRiskExposureBreakdown.highRiskAmount` | Two further notes for integrators: - The report contains internal bookkeeping fields and provider-identifying values that are **not part of the contract** (listed in the reference). Bind only to documented fields; treat unknown keys as ignorable. - Several values are not the type you would expect — dates are formatted like `12 Sep 2023` rather than ISO 8601, and some numbers and booleans arrive as strings. The reference calls out each one. ## Errors | HTTP | When | Notes | |---|---|---| | 400 | Neither `walletAddress` nor `transactionDetail` provided; invalid `direction`; missing or invalid `channel`; other validation errors | `message` describes the failure | | 401 | Missing / invalid / deleted API key | | | 402 | Insufficient credits | `{"message": "Insufficient credits"}` | | 429 | Screening engine rate limit (after automatic retries) | Retry later | | 502 | Screening engine unavailable | Retry later | | 504 | Screening did not complete within 60 seconds | Safe to retry | Every failed call is automatically refunded — you are only charged for successful screens. ## Latency and timeouts Screening is an asynchronous scan behind the scenes: the server initiates a scan and polls until completion, waiting up to **60 seconds**. Typical calls take a few seconds to tens of seconds. Set your HTTP client timeout to **at least 90 seconds**. A `504` means the scan did not finish in time; the charge is refunded and the request can be retried. ## Examples Screen a wallet: ```bash curl -X POST https://www.metacomp.ai/api/v1/transAndWallet \ -H "Authorization: Bearer sk-your-key" \ -H "Content-Type: application/json" \ -d '{ "network": "Ethereum", "channel": "api", "walletAddress": "0x1234abcd..." }' ``` Screen an incoming transaction (also screens the sender's wallet): ```bash curl -X POST https://www.metacomp.ai/api/v1/transAndWallet \ -H "Authorization: Bearer sk-your-key" \ -H "Content-Type: application/json" \ -d '{ "network": "Ethereum", "channel": "api", "transactionDetail": { "hash": "0x9f8e...", "asset": "USDT", "direction": "received", "from": "0xSenderAddress...", "to": "0xYourAddress..." } }' ``` --- # Concepts URL: https://www.metacomp.ai/developers/vision-x/concepts > Core concepts behind VisionX risk assessment — risk levels, exposure categories, transaction timeline, and cross-vendor verdicts. This page explains the data model VisionX uses so you can correctly interpret its output. ## Risk level Every check produces a **categorical risk level** — not a numeric score. The level summarises the overall concern associated with an address or transaction, derived by aggregating findings across all analytics providers queried in that call. A wallet report carries its level in `level`; a transaction report carries one per transaction in `txRiskLevel`. Levels observed today are `Low` and `High`. Treat the set as open: handle an unrecognised level as "needs review" rather than assuming only two values exist. ## Exposure categories Exposure is reported per counterparty category. Each counterparty in a wallet report carries a category label plus an `isHighRisk` flag saying whether that label is one the platform treats as high-risk. The platform's high-risk set is broader than the four categories below — it also includes `Theft`, `Malware`, `Extortion`, `Gambling`, and `High Risk Organisation` — and counterparty labels include plenty of non-risk types (`Exchange`, `Defi`, `Service`, `Smart Contract Platform`, `Others`). Always read `isHighRisk` rather than matching category names yourself; see the [Response Reference](/developers/vision-x/responses#risk-exposure) for the exact fields. The four categories below are the ones that most often drive an AML decision. ### Sanctions Exposure to addresses or entities listed by government sanctions bodies (e.g. OFAC, EU, UN). Sanctions exposure is the most severe category and indicates a legal obligation to block or escalate the transaction in most jurisdictions. ### Scams Association with addresses linked to known fraud schemes, phishing operations, rug pulls, or other deceptive activity. Scam exposure indicates that funds may have passed through or originated from fraudulent actors. ### Mixers Interaction with cryptocurrency mixing or tumbling services, which are designed to obscure the origin and flow of funds. Mixer exposure is a common AML red flag because it signals deliberate obfuscation of fund provenance. ### Darknet Connection to addresses associated with darknet marketplaces or services. Darknet exposure indicates that funds may be linked to illicit goods or services traded on anonymous platforms. ## Transaction timeline The transaction timeline shows the historical activity of a wallet — the sequence of inbound and outbound transfers over time. It provides context for the risk level by revealing patterns such as rapid fund movement, concentration of activity around specific counterparties, or sudden changes in volume. ## Cross-vendor verdict VisionX queries multiple on-chain analytics providers in a single call. Rather than returning a result from one provider and discarding the rest, it: 1. Collects a risk assessment from each provider independently. 2. Produces a **per-vendor breakdown** — showing how each provider scored the address or transaction. 3. Derives a **unified verdict** — a single authoritative conclusion that reconciles the per-vendor findings. This approach surfaces disagreements between providers and prevents false negatives that arise when any single vendor has incomplete coverage of a particular address or network. --- # Automated Compliance Pipeline URL: https://www.metacomp.ai/developers/vision-x/guides/automated-compliance-pipeline > Run VisionX wallet and transaction screening unattended inside Claude Code, Cursor, or Cline. Because both VisionX tools are read-only, they are safe to call inside an automated loop without requiring human confirmation at each step. This guide shows how to wire them into a batch compliance pipeline running inside Claude Code. ## Scenario You have a list of incoming transfers and need to screen each wallet and transaction before processing. Running this as an agent loop lets you check dozens of addresses in a single session without switching tools. ## Ask in chat Give Claude Code a batch instruction referencing your address list: > Screen each of these wallets before I process the transfers. For any wallet whose risk level is above low, summarise the exposure categories and flag it for review: > > - 0xAbCd…1234 (ETH, incoming 500 USDT) > - 0xEfGh…5678 (ETH, incoming 1200 USDT) > - 0xIjKl…9012 (ETH, incoming 300 USDT) Claude Code iterates over the list, calls `VisionX` for each address, and collects the results into a structured summary. ## Call the tool For tighter control, drive the screening loop directly in your agent script. **Tool:** `VisionX` — pass `walletAddress` for per-address checks, or `transactionDetail` if you have a transaction hash. **Example loop prompt for Claude Code:** ``` For each address in the following list, call VisionX with network=Ethereum and return a table with columns: address, risk_score, flagged_categories, verdict. Addresses: 0xAbCd…1234 0xEfGh…5678 0xIjKl…9012 ``` Because `VisionX` is read-only, Claude Code can call it without pausing for confirmation, making fully unattended batch runs practical. ## What you get back Each call returns a risk assessment payload — risk level, exposure categories, transaction timeline, and cross-vendor comparison. See [Response Reference](/developers/vision-x/responses) for the full response shape. ## Setup To use VisionX tools inside Claude Code, add the MetaComp MCP server first. See [Claude Code — AI Client Setup](/developers/getting-started/ai-clients/claude-code) for the one-line `claude mcp add` command and Skill package import. --- # Investigate a Transaction URL: https://www.metacomp.ai/developers/vision-x/guides/investigate-a-transaction > Retrieve transaction risk signals and the counterparty wallet report in a single VisionX call. When a transaction looks suspicious — or you want to verify a completed transfer before releasing funds — VisionX checks both the transaction itself and the counterparty wallet in one call, returning a combined report. ## Ask in chat Paste the transaction hash into any conversation and ask: > Check this USDT transfer: `0xDeFg…` The AI client recognises the transaction hash, calls `VisionX` automatically, and presents the full risk report. ## Call the tool If you are building an automated workflow, call the tool directly. **Tool:** `VisionX` **Key parameters:** | Parameter | Value | |---|---| | `network` | `Ethereum` (or `Bitcoin` / `Tron`) | | `transactionDetail` | A single transaction object (see below) | The `transactionDetail` object needs: ```json { "hash": "0xDeFg…", "asset": "USDT", "direction": "received", "from": "0xSender…", "to": "0xRecipient…" } ``` One call screens one transaction. To investigate several, call once per transaction — each call also screens that transaction's counterparty wallet, and each is billed once. ## What you get back The response contains transaction-level risk signals alongside the counterparty wallet report — both in a single payload. This means you get the transaction assessment and the full wallet screening of the counterparty without making a separate wallet-screening call. See [Response Reference](/developers/vision-x/responses) for the full response shape and field descriptions. --- # Screen a Wallet URL: https://www.metacomp.ai/developers/vision-x/guides/screen-a-wallet > Check a wallet address for risk before sending funds using VisionX. Before sending funds to an unfamiliar address, use VisionX to screen it for sanctions exposure, scam associations, mixer links, and darknet connections — without leaving your AI client. ## Ask in chat Paste the wallet address into any conversation and ask naturally: > Is `0xAbCd…1234` safe to send ETH to? The AI client detects the wallet address, calls `VisionX` automatically, and returns the risk report inline. ## Call the tool If you are building an automated workflow, call the tool directly. **Tool:** `VisionX` **Key parameters:** | Parameter | Example value | |---|---| | `network` | `Ethereum` | | `walletAddress` | `0xAbCd…1234` | The tool is read-only and requires no confirmation step, making it safe to invoke inside an automated pipeline. ## What you get back The response contains a risk level, an exposure breakdown by counterparty category (each entry flagged high-risk or not), a transaction timeline for the wallet, and a cross-vendor comparison showing how each analytics provider assessed the address. See [Response Reference](/developers/vision-x/responses) for the full response shape and field descriptions. --- # VisionX Overview URL: https://www.metacomp.ai/developers/vision-x > KYT and Web3 risk screening for Bitcoin, Ethereum, and Tron — via MCP inside your AI client, or over a direct REST API. **VisionX is KYT for AI agents — screen any wallet or transaction for risk before you act.** VisionX is MetaComp's Know Your Transaction (KYT) and Web3 security product. It screens wallet addresses and transactions for risk across Bitcoin, Ethereum, and Tron — without leaving your AI client. VisionX aggregates signals from multiple on-chain analytics providers simultaneously and returns a unified risk verdict. Every check produces a cross-vendor comparison alongside the overall score, so you are never relying on a single data source. There are two ways to integrate: - **MCP (AI clients)** — one tool, **`VisionX`**, which your client calls automatically when you reference a wallet address or transaction hash. Screen a wallet, a single transaction, or both in one call; screening a transaction also screens its counterparty wallet. Returns a risk level, exposure by counterparty category, transaction timeline, and a per-vendor comparison. - **API** — one REST endpoint, `POST /api/v1/transAndWallet`, for backends and services that integrate over plain HTTPS without an MCP client. See [API](/developers/vision-x/api). Both MCP tools and the Direct API are read-only and available in all environments. Supported networks: **Bitcoin**, **Ethereum**, **Tron**. } title="Concepts" href="/developers/vision-x/concepts" description="Risk levels, exposure categories, and cross-vendor verdict explained." /> } title="Screen a Wallet" href="/developers/vision-x/guides/screen-a-wallet" description="Step-by-step guide to checking a counterparty wallet before sending funds." /> } title="Investigate a Transaction" href="/developers/vision-x/guides/investigate-a-transaction" description="Review a completed or pending transaction for risk signals and counterparty exposure." /> } title="Automated Pipeline" href="/developers/vision-x/guides/automated-compliance-pipeline" description="Run unattended batch screening inside Claude Code, Cursor, or Cline." /> } title="MCP Tool" href="/developers/vision-x/tools" description="Parameter reference for the VisionX MCP tool." /> } title="API" href="/developers/vision-x/api" description="Call VisionX over plain HTTPS — screen wallets and transactions without an MCP client." /> } title="Response Reference" href="/developers/vision-x/responses" description="Field-level reference: wrapper, report bodies, exposure fields, and error shapes." /> --- # Response Reference URL: https://www.metacomp.ai/developers/vision-x/responses > Field-level response reference for VisionX screening results — the success wrapper, the wallet and transaction report bodies, exposure fields, and per-provider breakdowns. Every VisionX screening result — whether it reaches you through the [MCP tool](/developers/vision-x/tools) or the [API](/developers/vision-x/api) — uses the same wrapper and the same report body. This page is the field reference for both. Inside Claude or another MCP client you normally do not parse this yourself: the client renders the report as readable prose. Bind to the fields below when you integrate directly over the API, or whenever you drive an automated decision from the result. ## Success wrapper ```json { "success": true, "code": 0, "data": {} } ``` | Field | Type | Description | |---|---|---| | `success` | boolean | **The authoritative success signal.** `true` when the screening completed. | | `code` | number | Business status code. VisionX returns `0` on success. Treat `success` as the source of truth and **do not branch on specific numeric values** — the numbering scheme differs between MetaComp subsystems. | | `data` | object | The screening report. Its shape depends on `data.type`, below. | ## Report body (`data`) Common to both report types: | Field | Type | Description | |---|---|---| | `type` | string | `"wallet"` for a wallet report, `"transaction"` for a transaction report. Branch on this. | | `network` | string | The screened network, echoed from the request. | | `address` | string \| null | Wallet reports: the screened address. Transaction reports: `null`. | | `level` | string \| null | Wallet reports: the overall risk level — observed values `Low` and `High`. Transaction reports: `null`, with per-transaction risk in `extra.selectedTx[].txRiskLevel`. Treat this as an open set of strings rather than a closed two-value enum. | | `createTime` | string | When the screening ran, formatted `YYYY-MM-DD HH:mm:ss`. **No timezone or offset is included.** | | `extra` | object | The report detail — see the two sections below. | The report also carries internal bookkeeping fields — `id`, `tenantId`, `bid`, `email`, `status`, `deleted`, `createBy`, `updateBy`, `createUser`, `updateUser`. These are **not part of the contract**: they may change value, change meaning, or disappear without notice. Do not read, store, or display them. ## Wallet report (`extra`) ### Totals and activity | Field | Type | Description | |---|---|---| | `totalIncoming` / `totalOutgoing` | number | Total inbound / outbound value seen for the address, in USD. | | `walletBalance` | number | Balance in USD. | | `earliestTransactionTime` / `latestTransactionTime` | string \| null | First / last observed activity, formatted like `12 Sep 2023`. **Not ISO 8601** — parse accordingly. `null` when the address has no observed activity. | | `progress` | number | `100` when the screening finished; always `100` in a successful response. | ### Counterparty breakdown Four arrays describe who the address transacted with, split by direction and by hops: | Field | Description | |---|---| | `directIncoming` / `directOutgoing` | Counterparties one hop away, inbound / outbound. | | `indirectIncoming` / `indirectOutgoing` | Counterparties further upstream / downstream. | Every entry in all four arrays has the same shape: | Field | Type | Description | |---|---|---| | `tagTypeVerbose` | string | The counterparty's category label, e.g. `Service`, `Defi`, `Exchange`, `Others`, `Smart Contract Platform`, `Malware`, `Theft`, `Scams`. | | `isHighRisk` | boolean | `true` when `tagTypeVerbose` is one of the high-risk categories. **This is the flag to make decisions on.** | | `totalValueUsd` | number | Value attributed to this counterparty category, in USD. | | `totalValueUsdRatio` | number | That value as a percentage of the direction's total (`0`–`100`). | ### Risk exposure | Field | Type | Description | |---|---|---| | `incomingDirectExposure` / `outgoingDirectExposure` | array | The `isHighRisk: true` entries of the corresponding direct breakdown, same item shape as above. An empty array means no direct high-risk exposure. | | `incomingIndirectExposure` / `outgoingIndirectExposure` | array | The same, for the indirect breakdowns. | | `incomingRiskExposureBreakdown` / `outgoingRiskExposureBreakdown` | object | `{ totalAmount, lowRiskAmount, highRiskAmount }` in USD — that direction's total value split into low- and high-risk. | | `highRiskSumOfTaintedExposure` | object | Optional `incoming` / `outgoing` sums in USD; `{}` when there is nothing to report. | | `highRiskCategories` | array | High-risk category labels, e.g. `Sanctions`, `Scams`, `Theft`, `Malware`, `Coin Mixer`, `Darknet`, `Gambling`, `Extortion`, `High Risk Organisation`. | See [Concepts](/developers/vision-x/concepts) for what the main risk categories mean and how the risk level is derived. ### Per-provider breakdown VisionX screens against several analytics providers and returns each one's view alongside the aggregate, under the keys `vendor1`, `vendor2`, `vendor3`. Each block repeats the wallet report's totals, counterparty breakdown and exposure fields, scoped to that provider, and adds: | Field | Type | Description | |---|---|---| | `platformWalletAlert` | object | That provider's alert flags: `hasAlert`, `hasDirectAlert`, `hasSevereDirectAlert`, `cumulativeOrProhibitedMoreThanThreshold`. Each is `true`, `false`, or `null` when the provider did not report on it. | Before you depend on this section: - A `vendorN` key maps to the same provider on every call, so per-provider results are comparable across calls and over time. - A key is **absent** when that provider returned nothing for the address, and additional provider keys may appear alongside the three above. Iterate over whatever is present; do not assume a fixed set and do not infer anything from key order. - Provider-identifying values inside these blocks (such as `platform`) are internal and **not part of the contract**. ## Transaction report (`extra`) | Field | Type | Description | |---|---|---| | `tx` | array | The submitted transactions, each carrying at least `hash`. | | `total` | number | Number of transactions in the screening. | | `selectedTx` | array | The per-transaction findings — see below. | Each `selectedTx[]` entry: | Field | Type | Description | |---|---|---| | `txHash` | string | The transaction hash. | | `txRiskLevel` | string | Risk level for this transaction, e.g. `Low`. This — not `data.level` — is the transaction verdict. | | `date` | string | Transaction date, formatted like `31 Jul 2026`. **Not ISO 8601.** | | `direction` | string | `sent` or `received`, echoed from the request. | | `fromAddress` / `toAddress` | string | The transfer's endpoints. | | `asset` | object | `{ asset, amount, usdValue }` — symbol plus amount and USD value. **`amount` and `usdValue` are strings**, not numbers. | | `directExposure` | string | `"Yes"` / `"No"` — a **string**, not a boolean. | | `riskSources` | array | `{ source, ratio }` entries attributing risk to sources. Both fields carry the string `"N/A"` when nothing was attributed — check for that sentinel before parsing `ratio` as a number. | Per-provider alert objects also appear on each entry, keyed by internal provider identifiers and shaped like `platformWalletAlert` above. The caveats from the wallet report's per-provider section apply here too: treat those keys and any provider-identifying values as non-contractual. ## Errors A failed screening never arrives as a `success: false` body — it surfaces as a non-2xx status (API) or a tool error (MCP). See [Status & Errors](/developers/reference/status-and-errors) for the error shapes and retry guidance, and the [API](/developers/vision-x/api) page for the endpoint's status codes. ## Fields not listed here The report can contain fields beyond the ones above. They are implementation detail: they may change or disappear without notice and are not covered by this reference. Bind only to documented fields, and treat unknown keys as ignorable. --- # MCP Tool URL: https://www.metacomp.ai/developers/vision-x/tools > Parameter reference for the VisionX MCP tool — screen a wallet, a single transaction, or both in one call. The hosted MetaComp MCP server at `https://www.metacomp.ai/mcp` exposes VisionX as a **single tool**, `VisionX`. It is read-only and available in all environments — your AI client calls it automatically when you reference a wallet address or transaction hash, with no explicit invocation required. At the MCP tool layer, `network` is required. In natural-language clients the AI may infer it and fill it in when the input is unambiguous, but direct MCP integrations should always pass `network` explicitly. ## VisionX Check the security of a Web3 wallet and/or a single transaction in one call. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `network` | string | yes | One of `Bitcoin`, `Ethereum`, `Tron` | | `walletAddress` | string | one of | Wallet address to screen (e.g. `0x…`) | | `transactionDetail` | object | one of | A single transaction to screen — fields below | Pass `walletAddress`, `transactionDetail`, or both; at least one is required. **`transactionDetail` object** (all fields required) | Field | Type | Notes | |---|---|---| | `hash` | string | Transaction hash | | `asset` | string | Asset name (e.g. `ETH`, `USDT`) | | `direction` | string | `received` or `sent` | | `from` | string | Sender address | | `to` | string | Recipient address | **Returns** `{ transactionCheck, walletCheck }` — two screening results in one response: - `walletCheck` — a wallet report. When you pass `transactionDetail` this covers the transaction's **counterparty**, resolved from `direction` (`received` → its `from`, `sent` → its `to`); otherwise it covers `walletAddress`. - `transactionCheck` — the transaction report, or `null` when you passed no `transactionDetail`. Both objects follow the wrapper and field contract in the [Response Reference](/developers/vision-x/responses). One call screens **one** transaction. To screen several, call once per transaction — each call is billed once and screens that transaction's counterparty. **Example prompts** > Is `0xAbCd…1234` safe to send ETH to? > Check this USDT transfer: `0xDeFg…` --- ## Legacy local package The npm package `@metacomp/visionx-kyt-mcp`, used by [Claude Desktop](/developers/getting-started/ai-clients/claude-desktop), is a **separate legacy server** that runs on your machine and reaches deprecated backend endpoints. It exposes two older tools instead of the one above — `get_wallet_security` and `get_transaction_security` — with different parameters, and it covers VisionX only (no AgentX tools). New integrations should use the hosted server or the [API](/developers/vision-x/api). --- # Accounts & Balances URL: https://www.metacomp.ai/developers/financial-services/accounts > How to query MetaComp account summaries and per-currency detail using get_account_summary, get_account_detail, and get_module_permissions. MetaComp accounts are partitioned into product sub-accounts. Three read-only tools let you inspect the current state of any account without side effects. For the full account model definition, see [Concepts](/developers/financial-services/concepts). --- ## get_account_summary Retrieve a high-level balance overview across all product accounts, expressed in USD. **Parameters** None. **Returns** An object with one key per product account category. Each category contains the same three fields: | Field | Type | Description | |---|---|---| | `availableAmount` | string | Amount available for immediate use, in USD (high-precision decimal string) | | `pendingAmount` | string | Aggregate pending debit — funds reserved for outgoing transactions, in USD | | `totalAmount` | string | Total balance including pending, in USD | **Categories returned:** | Key | Description | |---|---| | `fiat` | Fiat currency balance | | `crypto` | Cryptocurrency balance | | `investment_fiat` | Fiat locked in investment products | | `quarantine_portfolio` | Assets under compliance quarantine | | `investment_product` | Balance held in investment products | All amounts are in USD (the display currency) as high-precision decimal strings. Read-only. --- ## get_account_detail Fetch a per-currency breakdown for a specific product account. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `productCode` | string (enum) | yes | One of: `fiat`, `crypto`, `investment_fiat`, `quarantine_portfolio`, `investment_product`, `named_account` | **`productCode` values:** | Value | Meaning | |---|---| | `fiat` | Fiat currency account (USD, HKD, EUR, etc.) | | `crypto` | Cryptocurrency account (BTC, ETH, USDT, etc.) | | `investment_fiat` | Fiat funds locked in investment products | | `quarantine_portfolio` | Assets frozen under compliance review | | `investment_product` | Balance in investment products (FIP); `instrumentInfoMap` is always `{}` | | `named_account` | Same-name account — funds in accounts registered under the holder's own name | **Returns (success)** ```json { "data": { "holderCode": "IOTH0001", "productCode": "fiat", "availableAmount": "12345.67", "pendingAmount": "500.00", "totalAmount": "12845.67", "instrumentInfoMap": { "USD": { "availableAmount": "12000.00", "availableAmountDisplay": "12000.00", "pendingAmount": "500.00", "pendingCreditAmount": "0.00" }, "HKD": { ... } } } } ``` | Field | Type | Description | |---|---|---| | `data.holderCode` | string | Account holder participant code | | `data.productCode` | string | The product type queried | | `data.availableAmount` | string | Aggregate available balance in USD | | `data.pendingAmount` | string | Aggregate pending debit in USD | | `data.totalAmount` | string | Aggregate total in USD | | `data.instrumentInfoMap` | object | Per-currency breakdown, keyed by currency code. Empty (`{}`) for `investment_product`. | **`instrumentInfoMap[currency]` fields:** | Field | Type | Description | |---|---|---| | `availableAmount` | string | Available balance in the currency's native units (raw decimal string) | | `availableAmountDisplay` | string | Available balance converted to USD (short decimal string) | | `pendingAmount` | string | Outgoing pending debit in native units | | `pendingCreditAmount` | string | Incoming pending credit in native units (not yet settled) | Use `availableAmount` for same-currency comparisons (e.g. checking if the user has enough USDT to withdraw 100 USDT). Use `availableAmountDisplay` for cross-currency value comparisons in user-facing displays. **Returns (error / re-auth)** When the session has expired or the request fails, the tool returns an error object instead: ```json { "error": true, "message": "Session expired", "authUrl": "https://www.metacomp.ai/auth/..." } ``` See [Concepts — Error and re-authentication shape](/developers/financial-services/concepts#error-and-re-authentication-shape) for full details. Read-only. --- ## get_module_permissions Check which financial modules the current user has permission to access. **Parameters** None. **Returns** ```json { "permissions": [ { "module": "deposit", "hasPermission": true }, { "module": "otc", "hasPermission": true }, { "module": "withdrawal", "hasPermission": false }, { "module": "wealth", "hasPermission": true } ] } ``` | Field | Type | Description | |---|---|---| | `permissions` | array | One entry per module | | `permissions[].module` | string | Module identifier: `deposit`, `otc`, `withdrawal`, or `wealth` | | `permissions[].hasPermission` | boolean | Whether the user can access this module | Call this tool before attempting any module-specific operation. If `hasPermission` is `false`, do not attempt the operation and inform the user that access is not enabled for their account. Read-only. --- # Concepts URL: https://www.metacomp.ai/developers/financial-services/concepts > Core concepts for MetaComp AgentX — account model, currency typing, fees, minor units, verification codes, module permissions, and error shapes. This page defines the data model and conventions shared across all AgentX MCP tools. Read this before working with any AgentX tool. --- ## Account model A MetaComp account is partitioned into named sub-accounts called **product accounts**, each identified by a `productCode` enum value: | `productCode` | Description | |---|---| | `fiat` | Fiat currency account (USD, HKD, EUR, etc.) | | `crypto` | Cryptocurrency account (BTC, ETH, USDT, etc.) | | `investment_fiat` | Fiat funds currently locked in an investment product | | `quarantine_portfolio` | Assets frozen under compliance review | | `investment_product` | Balance held in investment products such as FIP | | `named_account` | Same-name account balance — funds held in accounts registered under the holder's own name | Use [`get_account_summary`](/developers/financial-services/accounts) to see USD-equivalent totals across all categories. Use [`get_account_detail`](/developers/financial-services/accounts) with a specific `productCode` to drill into individual currency balances. The `investment_product` account returns an empty `instrumentInfoMap` (`{}`); it has no per-currency breakdown. --- ## First-party vs third-party (COBO) Many deposit and withdrawal tools accept a `withdrawalParty` parameter that distinguishes between two counterparty modes: | Value | Meaning | |---|---| | `1` (integer) or `'first_party'` (string enum) | The account owner is the counterparty — own bank or wallet | | `2` (integer) or `'third_party'` (string enum) | A COBO third-party counterparty — someone else's bank or wallet | The exact type (integer `1`/`2` vs string `'first_party'`/`'third_party'`) varies per tool — see the individual tool parameter tables in [MCP Tools](/developers/financial-services/tools). **Third-party requirements:** - `purposeOfTransaction` (free text) is always required when `withdrawalParty = 2` on execute calls. - For **crypto** third-party withdrawals (`execute_crypto_withdrawal`), an uploaded proof document is also required: call `upload_file` first to obtain a file `id`, then pass that `id` as the `proof` parameter. --- ## Currency typing The `currencyType` parameter (used by `get_withdrawal_currencies`) encodes the asset class as an integer: | `currencyType` | Asset class | |---|---| | `1` | Fiat | | `2` | Crypto | `isSameNameAccount` is a fiat-only flag. It must be `false` or omitted when `currencyType = 2`. --- ## Fees and charge types **`chargeType`** (integer, used in `execute_fiat_withdrawal`) specifies who bears the bank transfer charge: | `chargeType` | Meaning | |---|---| | `1` | Fee borne by beneficiary | | `2` | Fee borne by sender | | `3` | Shared between both parties | **`feePayer`** (string enum, used in deposit estimate tools) controls service fee allocation: | `feePayer` | Meaning | |---|---| | `'paid_by_me'` | Fee deducted from the deposit amount — the user's net received amount is shown | | `'paid_by_third_party'` | Fee added on top — the payor's gross send amount is shown | Use `get_withdrawal_quote` before executing a withdrawal to retrieve both the service fee (`fee.serviceFee`) and the minimum allowed amount (`minimumAmount.minimumAmount`) in a single call. --- ## Minor units The history list endpoints — `get_deposit_list` and `get_withdrawal_list` — return monetary amounts as **integers in minor units** (e.g. cents for USD, satoshis for BTC): - `totalAmount`, `receiveAmount`, `chargeAmount` — all minor units. - Divide by `10^decimals` before displaying. The decimal precision per currency is determined by the product base list. **Example:** a USD amount of `150025` represents `$1,500.25` (USD has 2 decimal places). The execute tools (`execute_fiat_withdrawal`, `execute_crypto_withdrawal`) and account tools use decimal strings (`"1500.25"`) — no conversion needed. --- ## Verification codes The execute-level withdrawal tools (`execute_fiat_withdrawal`, `execute_crypto_withdrawal`) require a `verificationCode` parameter. This is a time-limited one-time code issued by MetaComp's security verification flow. MCP does not generate this code for you. Before calling an execute-level withdrawal tool: - Ensure the user has already obtained a currently valid verification code from MetaComp. - Treat the code as user-held input, not as a value that can be derived from another MCP tool call. - Do not cache or reuse an old code across sessions or after a failed attempt. - If the code is missing, invalid, or expired, stop the flow and ask the user to obtain a new one before retrying. Passing an invalid or expired code results in a server-side validation error. --- ## Module permissions Before attempting any operation, call `get_module_permissions` to verify the current user has access to the relevant module: | Module | Controls | |---|---| | `deposit` | `get_fiat_deposit_*`, `get_crypto_deposit_*`, `get_crypto_wallet_addresses`, deposit estimate/submit tools | | `otc` | `get_available_currency_pairs`, `get_exchange_quote`, `get_otc_quote`, `confirm_otc_trade`, `get_otc_trade_detail` | | `withdrawal` | `get_withdrawal_*`, `execute_fiat_withdrawal`, `execute_crypto_withdrawal`, `upload_file` | | `wealth` | `get_fip_products`, `get_fip_agreement`, `investor_precheck`, `fip_subscribe` | The tool returns an array of `{ module, hasPermission }` objects. Attempting a module operation without the corresponding permission will be rejected. In guided agent flows, check module permissions before offering destructive actions to the user. This avoids walking the user through a flow that their account cannot complete. --- ## Error and re-authentication shape All AgentX tools may return an error object instead of the normal success payload when the session is invalid or an operation fails: ```json { "error": true, "message": "Session expired", "authUrl": "https://www.metacomp.ai/..." } ``` | Field | Type | Description | |---|---|---| | `error` | `true` | Literal — always present on error responses | | `message` | string | Human-readable error description | | `authUrl` | string (optional) | Re-authentication URL; present when the session has expired and the user must log in again | When `authUrl` is present, direct the user to that URL to re-authenticate, then retry the operation. For OTC-specific errors (HTTP 410 / 409), see the [Response Reference](/developers/financial-services/responses). --- # Deposit Crypto URL: https://www.metacomp.ai/developers/financial-services/guides/deposit-crypto > Generate a wallet address and QR code for a first-party crypto deposit, or estimate a third-party (COBO) crypto deposit via the MCP API. Receive cryptocurrency into a MetaComp account by generating a deposit wallet address (first-party), or initiate a managed COBO transfer estimation for third-party scenarios. ## Before you start Call `get_module_permissions` and confirm the `deposit` module returns `hasPermission: true`. See [Module permissions](/developers/financial-services/concepts#module-permissions). ## The flow ### Path A — First-party deposit (receive into your own wallet address) **Discover currencies** — call `get_crypto_deposit_currencies` to list available crypto currencies for deposit. Use default parameters (first-party). **Select a network** — call `get_crypto_deposit_networks` (currency) to list the supported blockchain networks for the selected currency (e.g. `Ethereum`, `Tron`, `Bitcoin`). **Get the wallet address** — call `get_crypto_wallet_addresses` (network) to retrieve the user's deposit wallet address(es) for the selected network. Returns each entry with `walletAddress` and `qrCodeDataUrl` (base64 PNG). The QR code is also delivered as an MCP image content block — most clients render it inline. Tell the user "the QR code is shown above" rather than embedding the `data:` URL in markdown. No execute call is needed. The sender scans the QR or copies the wallet address and sends the funds on-chain. ### Path B — Third-party (COBO) deposit estimate **Discover currencies** — call `get_crypto_deposit_currencies` (`withdrawalParty: 'third_party'`) to list currencies available under the third-party COBO path. **Select a network** — call `get_crypto_deposit_networks` (currency, `withdrawalParty: 'third_party'`) to list networks supported for the third-party path. **Preview the deposit** — call `get_third_party_crypto_deposit_estimate` (network, currency, amount, feePayer) to preview the receiving wallet address, QR code, estimated service fee, and net/gross amounts. Show this to the user before they send funds. For `feePayer`: `'paid_by_me'` shows the net amount the user receives after fees; `'paid_by_third_party'` shows the gross amount the payor must send. See [Fees and charge types](/developers/financial-services/concepts#fees-and-charge-types). For the distinction between first-party and third-party, see [First-party vs third-party](/developers/financial-services/concepts#first-party-vs-third-party-cobo). ## Ask in chat > "Give me a USDT deposit address on the Tron network." The agent will call `get_crypto_deposit_currencies`, then `get_crypto_deposit_networks` (USDT), then `get_crypto_wallet_addresses` (Tron) and display your wallet address and QR code inline. ## What you get back `get_crypto_wallet_addresses` returns `addresses[]`, each with: - `walletAddress` — the on-chain deposit address to share or scan. - `qrCodeDataUrl` — base64 PNG QR; also sent as an MCP image block. `get_third_party_crypto_deposit_estimate` returns `walletAddress`, `qrCodeDataUrl`, `amountSent`, `estimatedServiceFee`, and `estimatedAmountReceived`. For full field descriptions and the minor-units convention, see [Response Reference](/developers/financial-services/responses). --- # Deposit Fiat URL: https://www.metacomp.ai/developers/financial-services/guides/deposit-fiat > Wire fiat currency into your MetaComp account using first-party bank transfer, same-name (named account), or third-party (COBO) paths via the MCP API. Send fiat funds into a MetaComp account by wiring to MetaComp's bank details (first-party), using a registered named account (same-name), or initiating a managed COBO transfer (third-party). ## Before you start Call `get_module_permissions` and confirm the `deposit` module returns `hasPermission: true` before proceeding. If permission is missing, the downstream tools will be rejected. See [Module permissions](/developers/financial-services/concepts#module-permissions). ## The flow MetaComp supports three fiat deposit paths. Choose the one that matches the depositor relationship. ### Path A — First-party wire (account owner wires directly) **Discover currencies** — call `get_fiat_deposit_currencies` to list available fiat currencies (use default parameters for first-party). **Get the wire details** — call `get_deposit_bank_account` (currency) to retrieve MetaComp's receiving bank account details (IBAN, SWIFT/BIC, bank address) that the user should wire funds to. Show the returned bank details to the user. The user initiates the wire outside the MCP surface; no execute call is required. ### Path B — Same-name (named account) deposit **Discover currencies** — call `get_fiat_deposit_currencies` (`isSameNameAccount: true`) to list currencies available for named-account deposits. **Confirm same-name support** — call `get_named_account_currencies` to confirm which currencies support the same-name transfer path. **Retrieve named accounts** — call `get_named_account_list` to retrieve the user's registered named bank accounts (IBAN, SWIFT, owner name) to share with the sending bank. The user wires from their own registered bank account; no execute call is required. For an explanation of first-party vs third-party and what "named account" means, see [First-party vs third-party](/developers/financial-services/concepts#first-party-vs-third-party-cobo). ### Path C — Third-party (COBO) deposit **Discover currencies** — call `get_fiat_deposit_currencies` (`withdrawalParty: 'third_party'`) to list currencies available for third-party deposits. **List COBO payors** — call `get_fiat_deposit_bank_accounts` (`withdrawalParty: 'third_party'`) to list the configured COBO payor bank accounts (each with `baNumber`, owner info, and relationship). **Preview fees** — call `get_third_party_fiat_deposit_estimate` (currency, amount, feePayer, baNumber) to preview the fee breakdown and net/gross amounts before committing. Show the estimate to the user and ask for explicit confirmation. **Submit the deposit** — call `execute_third_party_fiat_deposit_submit` to submit the deposit request. Returns a `depositNumber` reference. Destructive — call this only after the user has explicitly confirmed the fee and amounts shown by `get_third_party_fiat_deposit_estimate`. For the `feePayer` field: `'paid_by_me'` deducts the fee from the deposited amount; `'paid_by_third_party'` adds it on top. See [Fees and charge types](/developers/financial-services/concepts#fees-and-charge-types). ## Ask in chat > "I want to deposit 5,000 USD into my MetaComp account. The funds are coming from a third-party COBO payor." The agent will call `get_fiat_deposit_currencies` (third_party), list your COBO payors via `get_fiat_deposit_bank_accounts`, calculate fees with `get_third_party_fiat_deposit_estimate`, and ask you to confirm before submitting. ## What you get back `execute_third_party_fiat_deposit_submit` returns `{ depositNumber }` — the unique deposit reference (e.g. `"DP2026..."`). For first-party and same-name paths, the bank wiring details are returned by `get_deposit_bank_account` or `get_named_account_list` respectively; the user completes the transfer through their bank. For full field descriptions and status conventions, see [Response Reference](/developers/financial-services/responses). --- # Exchange (OTC) URL: https://www.metacomp.ai/developers/financial-services/guides/exchange-otc > Execute a two-step OTC currency exchange — lock a quote, confirm at the live rate — using MetaComp's MCP API. Convert between fiat and crypto currencies via MetaComp's OTC desk in two steps: lock a quote, then confirm. The server re-prices at confirmation time, so the final settled rate may differ slightly from the quoted rate. ## Before you start Call `get_module_permissions` and confirm the `otc` module returns `hasPermission: true`. See [Module permissions](/developers/financial-services/concepts#module-permissions). ## The flow **Browse rates** — call `get_exchange_quote` (fromCurrency, toCurrency) to fetch the current indicative exchange rate without locking a quote or checking balance. Use this to browse rates or compute the source amount needed for a given target amount. This call is safe to repeat; it does not reserve any quote ID. **Lock a quote** — call `get_otc_quote` (fromCurrency, toCurrency, totalValue) _(Step 1 of 2)_ to lock a quote at a specific amount. Performs a backend balance check and per-currency limit check. Returns `quoteCode`, `exchangeRate`, `finalAmount`, `validityPeriod` (seconds), and `expiry` (ISO-8601 UTC). If `exchangeRate` or `finalAmount` is an empty string (`""`), the downstream pricing service cannot price this pair right now. Tell the user the rate is unavailable and do not proceed to `confirm_otc_trade`. Let the user retry later or pick a different pair. If `success: false`, show the `message` (e.g. insufficient balance, amount out of bounds) and return to currency selection. Do not auto-retry. Show `exchangeRate` and `finalAmount` to the user on a confirmation screen along with `validityPeriod` as a UX hint to confirm promptly. **Confirm the trade** — call `confirm_otc_trade` (quoteCode) _(Step 2 of 2 — destructive; trades at the live rate)_ to submit the trade using the `quoteCode` from the previous step. The server re-fetches a fresh quote and trades at the live rate; the final `exchangeRate` and `finalAmount` returned here are the **actual settled values** and may differ from the quoted values. Always display these as the final rate, not the quote-stage estimate. **HTTP 410** = quote context expired (5-minute server window elapsed). **HTTP 409** = live rate drifted beyond the system tolerance from the quoted rate. On either error, inform the user and call `get_otc_quote` again — do not auto-retry. **Inspect the settlement** — call `get_otc_trade_detail` (tradeCode) to inspect the full settlement record: status, trading pair, base/quote quantities, final price, and settlement timestamps. ## Ask in chat > "Convert 1,000 USD to USDT at the best available rate." The agent will browse the rate with `get_exchange_quote`, lock a quote via `get_otc_quote`, present the `exchangeRate` and `finalAmount` for your confirmation, then call `confirm_otc_trade` and display the settled rate and `tradeCode`. ## What you get back `confirm_otc_trade` returns: | Field | Description | |---|---| | `tradeCode` | Unique trade reference (e.g. `"OT2026..."`). Use as the user-facing transaction ID. | | `exchangeRate` | Actual rate at which the trade was executed. Show this as the **final settled rate**. | | `finalAmount` | Actual amount received in `toCurrency` at the executed rate. | | `point` | Loyalty/reward points earned (decimal string). | Use `get_otc_trade_detail` with the `tradeCode` to retrieve full settlement details at any time. For OTC-specific HTTP error handling and the quote code reference, see [Response Reference](/developers/financial-services/responses). --- # Transaction History URL: https://www.metacomp.ai/developers/financial-services/guides/transaction-history > Query paginated deposit and withdrawal history for your MetaComp account, with time-range filtering and per-record status details. Retrieve a paginated list of deposit or withdrawal records for a MetaComp account. Both tools return records newest-first and support optional time-range filtering. ## The flow ### Deposit history **Query deposit records** — call `get_deposit_list` (pageNum, pageSize, payeeAccountType, startTime?, endTime?) to retrieve deposit records. - `payeeAccountType: 1` = fiat deposits; `2` = crypto deposits. - `startTime` / `endTime` are optional; format: `"YYYY-MM-DD HH:mm:ss"` (e.g. `"2026-04-01 00:00:00"`). - Records are returned newest first. ### Withdrawal history **Query withdrawal records** — call `get_withdrawal_list` (pageNum, pageSize, payeeAccountType, startTime?, endTime?) to retrieve withdrawal records. - `payeeAccountType: 1` = fiat withdrawals; `2` = crypto withdrawals. - Same time-range format applies. ### "Did my deposit arrive?" pattern Use `pageNum: 1` and a small `pageSize` (e.g. `5`) to show the user the most recent entries. For deposits, check `status` / `statusDesc` on the matching `paymentCode`. For crypto deposits, the on-chain transaction hash is in the `detail` field. ## Ask in chat > "Did my USD deposit arrive? Show me the last 5 deposits." The agent will call `get_deposit_list` with `pageNum: 1`, `pageSize: 5`, `payeeAccountType: 1` and display the most recent fiat deposit records with their status. ## What you get back Both tools return a paginated response: | Field | Description | |---|---| | `total` | Total number of matching records | | `pages` | Total pages | | `pageNum` | Current page | | `pageSize` | Records per page | | `list[]` | Array of deposit / withdrawal records | Each record includes `paymentCode`, `status`, `statusDesc` (may be `null` — display the raw `status` with a note when null), `currency`, `totalAmount`, `receiveAmount`, and `chargeAmount`. **Minor units:** `totalAmount`, `receiveAmount`, and `chargeAmount` are integers in minor units (e.g. cents for USD). Divide by `10^decimals` before displaying. See [Minor units](/developers/financial-services/concepts#minor-units). For crypto deposits, the `detail` field contains the on-chain transaction hash. For third-party crypto deposits, `coboInfo.txHash` provides an additional copy. For the full field reference and status conventions, see [Response Reference](/developers/financial-services/responses). --- # Wealth (Fixed Income) URL: https://www.metacomp.ai/developers/financial-services/guides/wealth-fip > Subscribe to MetaComp Fixed Income Products (FIP) — flexible and fixed-term — after completing the investor precheck via the MCP API. Deploy idle balances into MetaComp's Fixed Income Products (FIP). FIPs offer both flexible (open-term) and fixed-term options across USD, USDT, USDC, BTC, and ETH, each with an estimated APR. ## Before you start Call `get_module_permissions` and confirm the `wealth` module returns `hasPermission: true`. See [Module permissions](/developers/financial-services/concepts#module-permissions). ## The flow **Run the investor precheck** — call `investor_precheck` to verify the user has signed the required agreements and completed the investor declaration before any FIP subscription. Returns two boolean flags: - `Master Brokerage Agreement & Trading Rules` — must be `true`. - `investorDeclarationTag` — must be `true`. Both flags must be `true` before calling `fip_subscribe`. If either is `false`, direct the user to complete the outstanding agreement or declaration via the MetaComp platform before continuing. **List available products** — call `get_fip_products` to list all available FIP products, both flexible (`termType: 1`) and fixed-term (`termType: 2`). Each product entry includes: - `productCode`, `productName`, `term` (human-readable label), `estApr` (estimated APR range). - `currencyItemList[]` — per-currency options with `id`, `currency`, `estApr`, `termDays`, `liquidity`, and `mhp` (minimum holding period). - Negative `termDays` values indicate flexible settlement products (e.g. T+1). **Retrieve the agreement** — call `get_fip_agreement` (productType, productCode, currency) to retrieve the PDF agreement documents for the selected product and currency. Present the `show_name` and `url` links to the user so they can review the agreement before subscribing. **Subscribe** — call `fip_subscribe` (id, currency, termDays, subscriptionAmount) to submit the subscription order. Destructive — confirm the product, currency, term, and subscription amount with the user before calling this tool. - `id` — the `currencyItemList[].id` from the product listing. - `currency` — must match the selected currency item. - `termDays` — use the `termDays` value from the currency item; negative values are used for flexible products. - `subscriptionAmount` — the amount to invest in the specified currency. `termType 1` = flexible / open term; `termType 2` = fixed term. ## Ask in chat > "I want to earn yield on my idle USDT. What fixed income products are available?" The agent will run `investor_precheck` to confirm eligibility, list products via `get_fip_products`, present the APR options and agreement links from `get_fip_agreement`, and then subscribe via `fip_subscribe` after your explicit confirmation. ## What you get back `fip_subscribe` returns a confirmation object with: | Field | Description | |---|---| | `currency` | Subscribed currency | | `subscriptionAmount` | Subscription amount | | `subscriptionDate` | Date the subscription was placed | | `returnsAccrualStartDate` | Date when yield begins to accrue | | `initialRedemptionOpeningDay` | Earliest date redemption is available | | `settlementDate` | Settlement date description | For full response conventions, see [Response Reference](/developers/financial-services/responses). --- # Withdraw Crypto URL: https://www.metacomp.ai/developers/financial-services/guides/withdraw-crypto > Withdraw cryptocurrency from your MetaComp account to a first-party or third-party wallet address via the MCP API. Send cryptocurrency out of a MetaComp account to an on-chain wallet address. First-party withdrawals go to the user's own registered wallets; third-party withdrawals require an uploaded proof document and a stated purpose. ## Before you start Call `get_module_permissions` and confirm the `withdrawal` module returns `hasPermission: true`. See [Module permissions](/developers/financial-services/concepts#module-permissions). A `verificationCode` is required by `execute_crypto_withdrawal`. Obtain it before calling execute. See [Verification codes](/developers/financial-services/concepts#verification-codes). Screen the destination address first. Before submitting any crypto withdrawal — especially to a third-party address — run the destination wallet through VisionX to detect sanctions exposure and on-chain risk. See [Screen a wallet](/developers/vision-x/guides/screen-a-wallet). ## The flow **List available currencies** — call `get_withdrawal_currencies` (`currencyType: 2`, `withdrawalParty: 1` or `2`) to list crypto currencies available for withdrawal. `currencyType: 2` = crypto. Use `withdrawalParty: 1` for first-party (own wallet) or `2` for third-party (beneficiary). See [Currency typing](/developers/financial-services/concepts#currency-typing) and [First-party vs third-party](/developers/financial-services/concepts#first-party-vs-third-party-cobo). **Get fees and limits** — call `get_withdrawal_quote` (currency, amount, `withdrawalParty`) to fetch the service fee and minimum withdrawal amount in a single call. Show both to the user before proceeding. **Resolve the destination wallet:** - **First-party:** call `get_crypto_withdrawal_wallets` (`withdrawalParty: 1`) to list the user's registered wallets (address, network, tag, owner name). Let the user pick one. - **Third-party:** The user supplies the wallet address directly. Call `upload_file` (fileBase64, originalName) to upload a supporting proof document (contract, agreement, or invoice). Capture the returned `id` — it is required as the `proof` parameter in the next step. **Submit the withdrawal** — call `execute_crypto_withdrawal` to submit the withdrawal. Required for all paths: `withdrawalParty`, `currency`, `amount`, `walletAddress`, `network`, `verificationCode`. **Third-party only:** `proof` (file `id` from `upload_file`) and `purposeOfTransaction` (free text) are both required. Calling this with `withdrawalParty: 2` without `proof` will fail server-side validation. This action is IRREVERSIBLE once broadcast to the network. Verify the wallet address, network, and amount carefully with the user before confirming. ## Ask in chat > "Withdraw 0.5 ETH to my registered Ethereum wallet." The agent will list available crypto currencies, fetch the fee via `get_withdrawal_quote`, show your registered wallets from `get_crypto_withdrawal_wallets`, and ask you to confirm before calling `execute_crypto_withdrawal`. ## What you get back `execute_crypto_withdrawal` returns `txCode` (unique reference, e.g. `"WD2026..."`), `currency`, `status`, `withdrawalAmount`, `chargeAmount`, `amountReceived`, `to` (destination address), and `network`. For the full response shape and status codes, see [Response Reference](/developers/financial-services/responses). --- # Withdraw Fiat URL: https://www.metacomp.ai/developers/financial-services/guides/withdraw-fiat > Withdraw fiat currency from your MetaComp account to a bank account — first-party or third-party — via the MCP API. Send fiat funds out of a MetaComp account to a destination bank account. Supports first-party (own account) and third-party (beneficiary) withdrawal paths, including same-name (named account) routing. ## Before you start Call `get_module_permissions` and confirm the `withdrawal` module returns `hasPermission: true`. See [Module permissions](/developers/financial-services/concepts#module-permissions). A `verificationCode` is required by `execute_fiat_withdrawal`. This is a time-limited one-time code issued by MetaComp's authentication layer. Obtain it before calling execute. See [Verification codes](/developers/financial-services/concepts#verification-codes). ## The flow **List available currencies** — call `get_withdrawal_currencies` (`currencyType: 1`, `withdrawalParty: 1` or `2`) to list fiat currencies available for withdrawal. Use `withdrawalParty: 1` for first-party (own bank) or `2` for third-party (beneficiary). For same-name path, add `isSameNameAccount: true`. `currencyType: 1` = fiat; see [Currency typing](/developers/financial-services/concepts#currency-typing). **Get fees and limits** — call `get_withdrawal_quote` (currency, amount, `withdrawalParty`) to retrieve the service fee (`fee.serviceFee`) and minimum withdrawal amount (`minimumAmount.minimumAmount`) in a single call. Show both to the user and confirm the amount is above the minimum. **Resolve the destination bank account:** - **Regular path:** call `get_fiat_withdrawal_bank_accounts` to list the user's bound non-same-name bank accounts. - **Same-name path:** call `get_named_account_list` to list the user's registered named accounts. **Submit the withdrawal** — call `execute_fiat_withdrawal` to submit the withdrawal. Required parameters: `withdrawalParty`, `currency`, `amount`, `bankAccountNumber`, `verificationCode`. For **third-party** (`withdrawalParty: 2`), `purposeOfTransaction` (free text) is also required. For same-name path, set `isSameNameAccount: true`. The `chargeType` parameter controls fee allocation: `1` = borne by beneficiary, `2` = borne by sender, `3` = shared. See [Fees and charge types](/developers/financial-services/concepts#fees-and-charge-types). Destructive — confirm the fee, minimum amount, and destination bank account with the user before calling this tool. For an explanation of first-party vs third-party and the same-name account concept, see [First-party vs third-party](/developers/financial-services/concepts#first-party-vs-third-party-cobo). ## Ask in chat > "Withdraw 2,000 USD to my bank account." The agent will check the available currencies, fetch the fee and minimum via `get_withdrawal_quote`, list your bound accounts via `get_fiat_withdrawal_bank_accounts`, and ask you to confirm before calling `execute_fiat_withdrawal`. ## What you get back `execute_fiat_withdrawal` returns a transaction record including `txCode` (unique reference, e.g. `"WD2026..."`), `currency`, `status`, `withdrawalAmount`, `chargeAmount`, and `amountReceived`. For the full response shape and status codes, see [Response Reference](/developers/financial-services/responses). --- # AgentX Overview URL: https://www.metacomp.ai/developers/financial-services > MetaComp AgentX — financial workflows via MCP tools, covering deposit, withdrawal, OTC exchange, transaction history, and wealth-product subscriptions. **AgentX is money movement for AI agents — deposit, withdraw, exchange, and invest.** Availability can vary by environment, rollout stage, and account permission set. Always check `get_module_permissions` at runtime before presenting an action as available. MetaComp AgentX exposes a suite of 32 MCP tools across the main financial workflows an agent needs: - **Deposit** — fiat and crypto deposit flows, including bank instructions, wallet addresses, supported networks, and estimate tools. - **Withdraw** — fiat and crypto withdrawal flows, including quotes, destination resolution, verification checks, and execution. - **OTC exchange** — quote, confirm, and trade-detail flows for currency conversion. - **Wealth** — wealth products, investor precheck, agreements, and FIP subscription flows. All tools are available through the MetaComp MCP server at `https://www.metacomp.ai/mcp`. Every functional area is gated by a permission module. Call `get_module_permissions` to check what the authenticated user can access (`deposit`, `otc`, `withdrawal`, `wealth`). ## Guides } title="Deposit Fiat" href="/developers/financial-services/guides/deposit-fiat" description="Get MetaComp's bank details and submit a third-party COBO fiat deposit request." /> } title="Deposit Crypto" href="/developers/financial-services/guides/deposit-crypto" description="Retrieve wallet addresses with QR codes and estimate third-party crypto deposits." /> } title="Withdraw Fiat" href="/developers/financial-services/guides/withdraw-fiat" description="Withdraw to a registered bank account (first-party or third-party)." /> } title="Withdraw Crypto" href="/developers/financial-services/guides/withdraw-crypto" description="Withdraw to a registered or external wallet (first-party or third-party)." /> } title="Exchange (OTC)" href="/developers/financial-services/guides/exchange-otc" description="Lock an indicative quote, confirm the trade, and look up settled trade details." /> } title="Wealth (Fixed Income)" href="/developers/financial-services/guides/wealth-fip" description="Browse FIP products, download agreements, and submit subscription orders." /> } title="Transaction History" href="/developers/financial-services/guides/transaction-history" description="Query paginated deposit and withdrawal transaction records." /> ## Reference } title="Accounts & Balances" href="/developers/financial-services/accounts" description="Query account summaries, per-currency balances, and module permissions." /> } title="Concepts" href="/developers/financial-services/concepts" description="Account model, currency typing, fee conventions, minor units, and error shapes." /> } title="MCP Tools" href="/developers/financial-services/tools" description="Complete parameter tables for all 32 AgentX MCP tools." /> --- # Response Reference URL: https://www.metacomp.ai/developers/financial-services/responses > Shared response conventions for AgentX MCP tools — minor units, status fields, OTC trade codes, re-authentication shape, and OTC two-step error model. This page documents the response conventions shared across all AgentX tools. For tool-specific return shapes, see [MCP Tools](/developers/financial-services/tools). For status code and error-handling reference, see also [Status & Errors](/developers/reference/status-and-errors). --- ## Minor units in history lists The `get_deposit_list` and `get_withdrawal_list` tools return monetary amounts as **integers in minor units**, not as decimal strings. **Rule:** divide by `10^decimals` before displaying. | Field | Tool | Units | |---|---|---| | `totalAmount` | `get_deposit_list`, `get_withdrawal_list` | Minor units (integer) | | `receiveAmount` | `get_deposit_list`, `get_withdrawal_list` | Minor units (integer) | | `chargeAmount` | `get_deposit_list`, `get_withdrawal_list` | Minor units (integer) | | `totalChargeAmount` | `get_withdrawal_list` | Minor units (integer) | | `deductibleAmount` | `get_withdrawal_list` | Minor units (integer) | **Example:** `totalAmount: 150025` for USD = `$1,500.25` (USD has 2 decimal places). All other tools — account detail, execute tools, quote tools — use decimal strings (e.g. `"1500.25"`) and require no conversion. --- ## Deposit records — key status fields Each record in `get_deposit_list` carries: | Field | Type | Description | |---|---|---| | `paymentCode` | string | Unique deposit reference (e.g. `"DP2026040110300001"`) | | `status` | number | Deposit status code | | `statusDesc` | string or null | Human-readable status; may be `null` while the status-code mapping is pending — display the raw `status` with a note when `null` | | `currency` | string | Deposit currency code | | `detail` | string or null | For crypto deposits: the on-chain transaction hash. For fiat: usually `null` | | `coboInfo.txHash` | string or null | Additional copy of the on-chain tx hash for third-party crypto deposits | --- ## Withdrawal records — key status fields Each record in `get_withdrawal_list` carries: | Field | Type | Description | |---|---|---| | `paymentCode` | string | Unique withdrawal reference (e.g. `"WD2026042709550001"`) | | `status` | number | Withdrawal status code | | `statusDesc` | string or null | Human-readable status; may be `null` — display raw `status` with a note when `null` | | `currency` | string | Withdrawal currency code | | `paymentType` | number | `21` = first-party, `22` = third-party | | `purposeOfTransaction` | string or null | Purpose field; meaningful for `paymentType = 22` (third-party) only | | `pathTo` | string or null | Destination route, e.g. `"BANK"` | --- ## Execute withdrawal response `execute_fiat_withdrawal` and `execute_crypto_withdrawal` both return: | Field | Type | Description | |---|---|---| | `txCode` | string | Unique transaction tracking code (e.g. `"WD2026041121000001"`) | | `currency` | string | Currency code of the withdrawal | | `status` | number | Initial withdrawal status (e.g. `13` = fiat pending, `24` = crypto pending) | | `withdrawalAmount` | string (optional) | Original amount requested | | `chargeAmount` | string (optional) | Service fee charged | | `totalChargeAmount` | string (optional) | Total charges including service fee | | `amountReceived` | string (optional) | Net amount the beneficiary receives after fees | | `to` | string (optional) | Destination — bank account number or wallet address | | `network` | string or null (optional) | Blockchain network; `null` for fiat withdrawals | | `createAt` | string (optional) | Creation timestamp | | `updateAt` | string (optional) | Last status update timestamp | --- ## OTC trade codes The OTC two-step flow returns identifiers at each step: | Field | Source tool | Description | |---|---|---| | `quoteCode` | `get_otc_quote` | Identifies the locked quote; pass unchanged to `confirm_otc_trade` | | `tradeCode` | `confirm_otc_trade` | Unique trade reference (e.g. `"OT2026043015320000"`); use as the user-facing transaction ID | After confirming, use `get_otc_trade_detail` with the `tradeCode` to retrieve full settlement details (final rate, settlement timestamps, buyer/seller codes). --- ## Re-authentication error shape When a session has expired or authentication is required, tools return this object instead of the normal success payload: ```json { "error": true, "message": "Session expired", "authUrl": "https://www.metacomp.ai/auth/..." } ``` | Field | Type | Description | |---|---|---| | `error` | `true` (literal) | Always present on error responses | | `message` | string | Human-readable description of the error | | `authUrl` | string (optional) | Re-authentication URL; present when the user must log in again | When `authUrl` is present, redirect the user to that URL. After successful authentication, retry the original tool call. --- ## OTC two-step error model The `confirm_otc_trade` tool surfaces OTC failures as **HTTP errors**, not as `{ success: false }` payloads: | HTTP status | Meaning | Action | |---|---|---| | `410 Gone` | Quote context expired — the 5-minute server window elapsed | Inform the user; call `get_otc_quote` again to obtain a fresh quote | | `409 Conflict` | Live rate drifted beyond the system drift tolerance from the originally quoted rate | Inform the user of the rate change; call `get_otc_quote` again so they can review the new rate before confirming | Do **not** auto-retry on either error. The user must explicitly review the new quote before proceeding. The `get_otc_quote` response may also indicate rate unavailability: if `exchangeRate` or `finalAmount` is an empty string (`""`), the downstream pricing service cannot price this pair at that moment. Do not proceed to `confirm_otc_trade` — inform the user and let them retry or pick a different pair. For general status code and error handling, see [Status & Errors](/developers/reference/status-and-errors). --- # MCP Tools URL: https://www.metacomp.ai/developers/financial-services/tools > Complete parameter and return reference for all 32 AgentX MCP tools across payments (accounts, OTC exchange, fiat deposit, crypto deposit, withdrawal, history) and fixed income. All tools are available via the MetaComp MCP server at `https://www.metacomp.ai/mcp`. Check [module permissions](/developers/financial-services/accounts#get_module_permissions) before calling any module-specific tool. Cross-cutting concepts (minor units, `withdrawalParty`, `currencyType`, fee enums, verification codes) are defined in [Concepts](/developers/financial-services/concepts). --- ## Accounts ### get_account_summary Get a USD-equivalent balance summary across all product account categories. Read-only. **Parameters** None. **Returns** An object with keys `fiat`, `crypto`, `investment_fiat`, `quarantine_portfolio`, `investment_product`. Each key maps to `{ availableAmount, pendingAmount, totalAmount }` — all high-precision USD decimal strings. --- ### get_account_detail Fetch per-currency breakdown for a specific product account. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `productCode` | string (enum) | yes | `fiat` \| `crypto` \| `investment_fiat` \| `quarantine_portfolio` \| `investment_product` \| `named_account` | **Returns** On success: `{ data: { holderCode, productCode, availableAmount, pendingAmount, totalAmount, instrumentInfoMap } }`. `instrumentInfoMap` is keyed by currency code; each entry has `availableAmount`, `availableAmountDisplay`, `pendingAmount`, `pendingCreditAmount`. On session expiry: `{ error: true, message, authUrl? }`. See [Accounts & Balances](/developers/financial-services/accounts#get_account_detail). --- ### get_module_permissions Check which financial modules the authenticated user can access. Read-only. **Parameters** None. **Returns** `{ permissions: [{ module: 'deposit'|'otc'|'withdrawal'|'wealth', hasPermission: boolean }] }` --- ### get_available_currency_pairs List all currency pairs available for OTC exchange. Read-only. **Parameters** None. **Returns** `{ pairs: string[] }` — each element is a tradeable pair in `BASE/QUOTE` format (e.g. `"USD/USDC"`, `"GBP/USDT"`). --- ## OTC Exchange Requires `otc` module permission. The OTC flow is two steps: `get_otc_quote` → `confirm_otc_trade`. For error handling (HTTP 410 / 409), see [Response Reference](/developers/financial-services/responses#otc-two-step-error-model). ### get_exchange_quote Fetch the current from→to exchange rate without locking a quote or checking balance. Use for browsing rates or pre-lock math. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `fromCurrency` | string | yes | Source currency code (e.g. `"USD"`, `"USDT"`, `"SGD"`) | | `toCurrency` | string | yes | Target currency code (e.g. `"USDT"`, `"BTC"`, `"EUR"`) | **Returns** `{ rate: string }` — the decimal from→to exchange rate. Multiply `fromCurrency` amount by `rate` to get the `toCurrency` amount. Does not lock a quote or reserve balance. --- ### get_otc_quote Step 1 of OTC exchange. Locks a quote at a specific amount and performs a backend balance and limit check. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `fromCurrency` | string | yes | Source currency code (e.g. `"USD"`, `"USDT"`) | | `toCurrency` | string | yes | Target currency code (e.g. `"USDT"`, `"BTC"`) | | `totalValue` | string | yes | Amount to exchange in source currency (e.g. `"1000"`, `"500.50"`) | **Returns** On success: `{ quoteCode, exchangeRate, finalAmount, validityPeriod, fromCurrency, toCurrency, totalValue, expiry }`. On failure: `{ success: false, message }`. | Field | Type | Description | |---|---|---| | `quoteCode` | string | Pass unchanged to `confirm_otc_trade` | | `exchangeRate` | string | Locked from→to rate. May be `""` when pricing is unavailable — do **not** proceed to confirm in that case | | `finalAmount` | string | Estimated receive amount in `toCurrency`. May be `""` when pricing is unavailable | | `validityPeriod` | number | Seconds the user has to confirm (UX hint; the server keeps context for 5 minutes) | | `expiry` | string | Absolute expiry timestamp (ISO 8601 UTC) | Always display `exchangeRate` and `finalAmount` to the user before calling `confirm_otc_trade`. --- ### confirm_otc_trade Step 2 of OTC exchange. Executes the trade at the live rate. Destructive — requires explicit user confirmation before calling. The server re-fetches a fresh rate at confirm time; the executed `exchangeRate` and `finalAmount` in this response are the final settled values and may differ from the `get_otc_quote` values. Failures are HTTP errors: `410` = quote context expired; `409` = rate drift exceeded. On either error, do not auto-retry — call `get_otc_quote` again. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `quoteCode` | string | yes | `quoteCode` returned by `get_otc_quote` | **Returns** `{ id, tradeCode, point, exchangeRate?, finalAmount? }` | Field | Type | Description | |---|---|---| | `id` | number | Internal trade record ID | | `tradeCode` | string | Transaction reference code — show as the trade identifier | | `point` | string | Loyalty/reward points earned (decimal string) | | `exchangeRate` | string (optional) | Actual executed exchange rate | | `finalAmount` | string (optional) | Actual amount received in `toCurrency` | --- ### get_otc_trade_detail Look up the full detail of a settled or pending OTC trade by its `tradeCode`. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `tradeCode` | string | yes | OTC trade code (e.g. the code returned by `confirm_otc_trade`) | **Returns** `{ trade: object | null }` — `null` when no trade matches the code. `trade` fields: | Field | Type | Description | |---|---|---| | `tradeCode` | string | Unique OTC trade code | | `tradeStatus` | number | Status code (e.g. `1` = pending, `4` = settled) | | `tradingAction` | number | `1` = buy base, `2` = sell base | | `buyerCode` | string | Buyer participant code | | `buyerName` | string | Buyer display name | | `sellerCode` | string | Seller participant code | | `sellerName` | string | Seller display name | | `baseCurrency` | string | Base currency code | | `quoteCurrency` | string | Quote currency code | | `baseQuantity` | string | Quantity of base currency | | `quoteAmount` | string | Amount of quote currency exchanged | | `quotePrice` | string | Quoted rate before adjustments | | `finalPrice` | string | Final locked exchange rate | | `tradeTime` | string | Trade creation timestamp (ISO 8601) | | `settleTime` | string | Scheduled settlement timestamp (ISO 8601) | | `updatedTime` | string | Last status update timestamp (ISO 8601) | --- ## Fiat Deposit Requires `deposit` module permission. ### get_fiat_deposit_currencies List fiat currencies available for deposit. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | string (enum) | no | `'first_party'` or `'third_party'`. Defaults to first-party | | `isSameNameAccount` | boolean | no | `true` for named-account (same-name) deposit flow | **Returns** `{ currencies: string[] }` — available fiat currency codes (e.g. `"USD"`, `"EUR"`, `"GBP"`). --- ### get_deposit_bank_account Get MetaComp's bank account details for a given currency (where to wire funds). Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `currency` | string | yes | Fiat currency code (e.g. `"USD"`, `"EUR"`, `"GBP"`) | **Returns** `{ accounts: [{ ownerName, ownerAddress, ownerCountryCode, baNumber, swiftCode, bankName, bankAddress, countryCode }] }` — MetaComp's receiving bank account details. --- ### get_fiat_deposit_bank_accounts List payor bank accounts available for fiat deposit. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | string (enum) | yes | `'first_party'` or `'third_party'` | **Returns** `{ accounts: [{ baNumber, ownerName, ownerAddress?, ownerCountryCode?, swiftCode?, bankName?, bankAddress?, countryCode?, ownerType?, relationship?, ownerCorporateCountryCode?, baTag?, relationType? }] }` — payor bank accounts (own accounts for first-party; registered COBO payors for third-party). --- ### get_third_party_fiat_deposit_estimate Estimate a third-party (COBO) fiat deposit — fee calculation and bank account details. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `currency` | string | yes | Fiat currency code (e.g. `"USD"`) | | `amount` | string | yes | Deposit amount as positive decimal string | | `feePayer` | string (enum) | yes | `'paid_by_me'` or `'paid_by_third_party'` | | `baNumber` | string | yes | Payor bank account number — must be from `get_fiat_deposit_bank_accounts` | | `isSameNameAccount` | boolean | no | `true` for named-account flow | **Returns** `{ accountType: 'fiat', depositType, amountSent, estimatedServiceFee, estimatedAmountReceived, payorBankAccount, receiverBankAccount }`. Show fee and amounts to the user for confirmation before calling `execute_third_party_fiat_deposit_submit`. --- ### execute_third_party_fiat_deposit_submit Submit a third-party (COBO) fiat deposit request. Destructive — requires explicit user confirmation before calling. Call `get_third_party_fiat_deposit_estimate` first and confirm fee/amounts with the user before calling this tool. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `currency` | string | yes | Fiat currency code (e.g. `"USD"`) | | `amount` | string | yes | Deposit amount as positive decimal string | | `feePayer` | string (enum) | yes | `'paid_by_me'` or `'paid_by_third_party'` | | `baNumber` | string | yes | Payor bank account number (from `get_fiat_deposit_bank_accounts`) | | `isSameNameAccount` | boolean | no | `true` for named-account flow | **Returns** `{ depositNumber: string }` — the deposit requirement number (e.g. `"DP2026..."`). --- ### get_named_account_currencies List fiat currencies supported for same-name (named) account transfers. Read-only. **Parameters** None. **Returns** `{ currencies: string[] }` — currency codes supporting named-account deposits (e.g. `"SGD"`, `"EUR"`, `"USD"`). --- ### get_named_account_list Get the user's registered same-name (named) bank accounts for first-party fiat transfers. Read-only. **Parameters** None. **Returns** `{ accounts: [{ baNumber, ownerName, ownerAddress?, ownerCountryCode?, swiftCode?, bankName?, bankAddress?, countryCode?, ... }] }` — the user's bound same-name bank account details. Call `get_named_account_currencies` first to confirm the selected currency supports named-account transfers. --- ## Crypto Deposit Requires `deposit` module permission. ### get_crypto_deposit_currencies List crypto currencies available for deposit. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | string (enum) | no | `'first_party'` or `'third_party'`. Defaults to first-party | **Returns** `{ currencies: string[] }` — available crypto currency codes (e.g. `"USDT"`, `"BTC"`, `"ETH"`). --- ### get_crypto_deposit_networks Get available blockchain networks for depositing a specific cryptocurrency. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `currency` | string | yes | Crypto currency code (e.g. `"USDT"`, `"BTC"`, `"ETH"`) | | `withdrawalParty` | string (enum) | no | `'first_party'` or `'third_party'`. Defaults to first-party | **Returns** `{ networks: string[] }` — supported blockchain networks (e.g. `"Ethereum"`, `"Tron"`, `"Bitcoin"`). --- ### get_crypto_wallet_addresses Get the user's crypto deposit wallet addresses for a blockchain network, with QR codes. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `network` | string | yes | Blockchain network (e.g. `"Ethereum"`, `"Tron"`, `"Bitcoin"`) | **Returns** `{ addresses: [{ walletAddress, qrCodeDataUrl }] }`. QR codes are also shipped as MCP image content blocks — most clients render them inline. Do not attempt to render the `data:` URL via markdown `![]()` in chat UIs. --- ### get_third_party_crypto_deposit_estimate Estimate a third-party (COBO) crypto deposit — fee, wallet address, and QR code. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `network` | string | yes | Blockchain network (e.g. `"Tron"`, `"Ethereum"`, `"Bitcoin"`) | | `currency` | string | yes | Crypto currency code (e.g. `"USDT"`, `"BTC"`) | | `amount` | string | yes | Deposit amount as positive decimal string | | `feePayer` | string (enum) | yes | `'paid_by_me'` or `'paid_by_third_party'` | **Returns** `{ accountType: 'crypto', depositType, feePayer, amountSent, estimatedServiceFee, estimatedAmountReceived, walletAddress, qrCodeDataUrl }`. --- ## Withdrawal Requires `withdrawal` module permission. Always call `get_withdrawal_quote` before executing to confirm service fee and minimum amount. For third-party withdrawals, `purposeOfTransaction` is required on execute calls. ### get_withdrawal_currencies List currencies available for withdrawal. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `currencyType` | `1` or `2` (integer literal) | yes | `1` = fiat, `2` = crypto | | `withdrawalParty` | `1` or `2` (integer literal) | yes | `1` = first-party, `2` = third-party | | `isSameNameAccount` | boolean | no | Fiat only; `true` = same-name account path. Must be omitted or `false` when `currencyType = 2` | **Returns** `{ currencies: string[] }` — currency codes available for withdrawal. --- ### get_withdrawal_quote Get the service fee and minimum withdrawal amount in a single call. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | `1` or `2` (integer literal) | yes | `1` = first-party, `2` = third-party | | `currency` | string | yes | Uppercase alphanumeric currency code | | `amount` | string | yes | Withdrawal amount as positive decimal string | | `isSameNameAccount` | boolean | no | Fiat only | **Returns** `{ fee: { serviceFee: string }, minimumAmount: { minimumAmount: number } }`. --- ### get_fiat_withdrawal_bank_accounts List non-same-name fiat withdrawal bank accounts (regular bound accounts). Read-only. **Parameters** None. **Returns** `{ accounts: [{ baNumber, ownerName, ownerAddress?, ownerCountryCode?, swiftCode?, bankName?, bankAddress?, countryCode?, ownerType?, ... }] }`. For same-name accounts, use `get_named_account_list` instead. --- ### execute_fiat_withdrawal Execute a fiat withdrawal. Destructive — requires explicit user confirmation before calling. Confirm fee and minimum with `get_withdrawal_quote` and confirm the destination bank account with the user before calling this tool. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | `1` or `2` (integer literal) | yes | `1` = first-party, `2` = third-party | | `currency` | string | yes | Uppercase alphabetic fiat currency code | | `amount` | string | yes | Withdrawal amount as positive decimal string | | `bankAccountNumber` | string | yes | Destination bank account number | | `verificationCode` | string | yes | One-time verification code from MetaComp authentication | | `chargeType` | integer (1–3) | no | `1` = beneficiary bears fee, `2` = sender bears fee, `3` = shared | | `isSameNameAccount` | boolean | no | `true` for same-name account path (fiat only) | | `purposeOfTransaction` | string | conditional | Required when `withdrawalParty = 2` (third-party) | **Returns** `{ txCode, currency, status, withdrawalAmount?, chargeAmount?, totalChargeAmount?, amountReceived?, to?, network?, createAt?, updateAt? }`. See [Response Reference](/developers/financial-services/responses#execute-withdrawal-response). --- ### get_crypto_withdrawal_wallets Get crypto wallet addresses for withdrawal, filtered by party type. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | `1` or `2` (integer literal) | yes | `1` = first-party (own wallets), `2` = third-party (beneficiary wallets) | **Returns** `{ wallets: [{ walletAddress, network, walletTag, ownerName }] }`. --- ### execute_crypto_withdrawal Execute a cryptocurrency withdrawal. Destructive — requires explicit user confirmation before calling. Irreversible once broadcast to the network. For third-party (`withdrawalParty = 2`): call `upload_file` first to obtain a file `id`, then pass it as `proof`. Both `proof` and `purposeOfTransaction` are required for third-party. Missing either will fail server-side validation. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `withdrawalParty` | `1` or `2` (integer literal) | yes | `1` = first-party, `2` = third-party | | `currency` | string | yes | Uppercase alphanumeric crypto currency code | | `amount` | string | yes | Withdrawal amount as positive decimal string | | `walletAddress` | string | yes | Destination wallet address | | `network` | string | yes | Blockchain network (must be supported for the currency) | | `verificationCode` | string | yes | One-time verification code from MetaComp authentication | | `proof` | integer | conditional | File `id` from `upload_file`. Required when `withdrawalParty = 2` | | `purposeOfTransaction` | string | conditional | Free-text purpose. Required when `withdrawalParty = 2` | **Returns** `{ txCode, currency, status, withdrawalAmount?, chargeAmount?, totalChargeAmount?, amountReceived?, to?, network?, createAt?, updateAt? }`. See [Response Reference](/developers/financial-services/responses#execute-withdrawal-response). --- ### upload_file Upload a supporting document as a base64 string. Destructive — requires explicit user confirmation before calling. Required before `execute_crypto_withdrawal` when `withdrawalParty = 2`. The returned `id` is passed as `proof`. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `fileBase64` | string | yes | Base64-encoded file content. Max ~7M chars (≈ 5MB binary) | | `originalName` | string | yes | Original file name with extension (e.g. `"invoice.pdf"`). Recorded for audit trail | | `mimeType` | string | no | MIME type (e.g. `"application/pdf"`, `"image/png"`). Defaults to `"application/octet-stream"` | **Returns** `{ id: number, physicalName: string }`. Use `id` as the `proof` parameter in `execute_crypto_withdrawal`. --- ## History ### get_deposit_list Query paginated deposit transaction records. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `pageNum` | integer ≥ 1 | yes | Page number, starting from 1 | | `pageSize` | integer 1–100 | yes | Records per page (max 100) | | `payeeAccountType` | number | yes | `1` = fiat deposits, `2` = crypto deposits | | `startTime` | string | no | Start of time range: `"YYYY-MM-DD HH:mm:ss"` | | `endTime` | string | no | End of time range: `"YYYY-MM-DD HH:mm:ss"` | **Returns** `{ total, list, pageNum, pageSize, pages }`. Each `list` item: `{ paymentCode, status, statusDesc, currency, totalAmount, receiveAmount, chargeAmount, detail, createAt, updateAt, payerCode, payerName, payeeCode, payeeName, coboInfo, ... }`. Amounts (`totalAmount`, `receiveAmount`, `chargeAmount`) are **integers in minor units** — divide by `10^decimals`. See [Response Reference](/developers/financial-services/responses#minor-units-in-history-lists). --- ### get_withdrawal_list Query paginated withdrawal transaction records. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `pageNum` | integer ≥ 1 | yes | Page number, starting from 1 | | `pageSize` | integer 1–100 | yes | Records per page (max 100) | | `payeeAccountType` | number | yes | `1` = fiat withdrawals, `2` = crypto withdrawals | | `startTime` | string | no | Start of time range: `"YYYY-MM-DD HH:mm:ss"` | | `endTime` | string | no | End of time range: `"YYYY-MM-DD HH:mm:ss"` | **Returns** `{ total, list, pageNum, pageSize, pages }`. Each `list` item: `{ paymentCode, status, statusDesc, currency, totalAmount, receiveAmount, chargeAmount, paymentType, purposeOfTransaction, pathTo, fee, feeRate, detail, createAt, updateAt, coboInfo, poboInfo, ... }`. `paymentType`: `21` = first-party, `22` = third-party. Amounts are **integers in minor units** — divide by `10^decimals`. See [Response Reference](/developers/financial-services/responses#minor-units-in-history-lists). --- ## Fixed Income Requires `wealth` module permission. Always call `investor_precheck` before `fip_subscribe` to verify required agreements are signed. ### get_fip_products Query available MetaComp Wealth Fixed Income Products. Read-only. **Parameters** None. **Returns** `{ success, code, msg, data, currencyConvertInfoList? }` `data` is an array of products: | Field | Type | Description | |---|---|---| | `productCode` | string | Internal product code | | `productName` | string | Display name | | `productType` | string | Category (currently `FIP`) | | `term` | string | Human-readable term (e.g. `"Flexible"`, `"30 Days"`) | | `termType` | integer | `1` = flexible/open term, `2` = fixed term | | `sort` | integer | Sort order | | `estApr` | string | Estimated APR or range (percentage string) | | `currencyItemList` | array | Supported currency options (see below) | Each `currencyItemList` entry: | Field | Type | Description | |---|---|---| | `id` | string | Currency item unique identifier — pass to `fip_subscribe` | | `currency` | string | Currency code (e.g. `"USD"`, `"USDT"`, `"USDC"`, `"BTC"`, `"ETH"`) | | `estApr` | string | APR for this currency option | | `term` | string | Human-readable term | | `termType` | integer | `1` = flexible, `2` = fixed | | `termDays` | integer | Term in days; negative values indicate flexible settlement products | | `liquidity` | string | Settlement description (e.g. `"(T + 1 Settlement)"`) | | `mhp` | string | Minimum holding period description; empty string if not specified | | `issuer` | string | Issuer name | --- ### get_fip_agreement Query FIP agreement documents (PDF links) for a specific product and currency. Read-only. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `productType` | string | yes | Product category (e.g. `"FIP"`) | | `productCode` | string | yes | Product code (e.g. `"FIP_OpenTerm_T+1"`, `"FIP_30Days"`) | | `currency` | string | yes | Currency code (e.g. `"USD"`, `"USDT"`, `"USDC"`, `"BTC"`, `"ETH"`) | **Returns** `{ agreements: [{ product_type, product_code, currency, url, show_name, sort, term_days }] }`. `url` is a PDF download link. Present the agreement document to the user before subscribing. --- ### investor_precheck Check whether the user has completed required investor agreements and declarations. Read-only. **Parameters** None. **Returns** ```json { "Master Brokerage Agreement & Trading Rules": true, "investorDeclarationTag": false } ``` | Field | Type | Description | |---|---|---| | `Master Brokerage Agreement & Trading Rules` | boolean | Whether the Master Brokerage Agreement has been signed | | `investorDeclarationTag` | boolean | Whether the investor declaration has been completed | If either field is `false`, the user must complete that step before subscribing to a FIP product. --- ### fip_subscribe Subscribe to a MetaComp Wealth Fixed Income Product. Destructive — requires explicit user confirmation before calling. Call `investor_precheck` and present the `get_fip_agreement` document to the user before calling this tool. **Parameters** | Name | Type | Required | Notes | |---|---|---|---| | `id` | string | yes | Currency item ID from `get_fip_products` (`currencyItemList[].id`) | | `currency` | string | yes | Currency code (e.g. `"USD"`, `"USDT"`, `"USDC"`, `"BTC"`, `"ETH"`) | | `termDays` | integer | yes | Term length in days. Use negative values for flexible products (e.g. `-2` for T+1 settlement, `-1` for T+3) | | `subscriptionAmount` | number | yes | Subscription amount in the specified currency | **Returns** `{ success, code, msg, data, currencyConvertInfoList? }` `data` fields: | Field | Type | Description | |---|---|---| | `currency` | string | Subscribed currency | | `subscriptionAmount` | string | Confirmed subscription amount | | `subscriptionDate` | string or null | Subscription date (e.g. `"2026-04-09"`); null if not yet determined | | `returnsAccrualStartDate` | string or null | Date returns start accruing; null if not yet determined | | `initialRedemptionOpeningDay` | string or null | Earliest redemption date; null if not yet determined | | `settlementDate` | string or null | Settlement date; null if not yet determined | --- # Rate Limits URL: https://www.metacomp.ai/developers/reference/rate-limits > MetaComp's request-rate posture, backoff guidance, and the rule against auto-retrying destructive operations. MetaComp does not publish specific numeric rate limits (requests per minute, concurrent connections, etc.) in this documentation. This page describes the expected behaviour, how to write well-behaved clients, and what to do if you need higher throughput. --- ## General posture MetaComp's MCP server is designed for conversational and agentic workloads — a user asking questions or an automated pipeline running sequential compliance checks. The server applies rate controls appropriate to this usage model. **What this means in practice:** - Make requests at a pace consistent with the task at hand. Do not fire tool calls in tight loops or fan out many parallel calls simultaneously. - If you receive an error response that indicates throttling or resource exhaustion, back off before retrying. - For read-only tools (e.g. `VisionX`, `get_deposit_list`), a simple exponential backoff is appropriate: wait 1 second after the first failure, double on each subsequent failure, and cap at a reasonable ceiling (e.g. 30 seconds). --- ## Destructive operations: never auto-retry Certain tools execute irreversible financial actions. These must **never** be auto-retried on failure: | Tool | Action | |---|---| | `confirm_otc_trade` | Locks an OTC trade at the quoted rate | | `execute_fiat_withdrawal` | Submits a fiat withdrawal | | `execute_crypto_withdrawal` | Submits a crypto withdrawal | If any of these return an error, surface the error to the user and wait for **explicit re-confirmation** before submitting a new request. Silently retrying a withdrawal or trade confirmation is a safety violation. For OTC-specific errors (`410 Gone` — quote expired, `409 Conflict` — rate drift), the correct action is to call `get_otc_quote` again and present the updated quote to the user. See [Status & Errors](/developers/reference/status-and-errors) for the full error reference. --- ## Handling backoff in code When a read-only tool call fails with a transient error, apply exponential backoff: ```js async function callWithBackoff(toolFn, maxAttempts = 4) { for (let attempt = 0; attempt < maxAttempts; attempt++) { try { return await toolFn(); } catch (err) { if (attempt === maxAttempts - 1) throw err; const delayMs = Math.min(1000 * 2 ** attempt, 30_000); await new Promise(r => setTimeout(r, delayMs)); } } } ``` Do not apply this pattern to destructive operations. --- ## Requesting higher throughput Specific quotas are not published here. If your integration requires a throughput level beyond what the server permits, contact the MetaComp team to discuss your use case. See [Support](/developers/resources/support) for contact details. --- ## Cross-references - [Status & Errors](/developers/reference/status-and-errors) — full error shapes including OTC HTTP 410 / 409. - [Support](/developers/resources/support) — contact and escalation options. --- # Status & Errors URL: https://www.metacomp.ai/developers/reference/status-and-errors > Complete reference for MetaComp MCP tool responses — the success wrapper, re-authentication errors, credit/metering errors (HTTP 402), OTC quote errors (HTTP 410/409), validation errors, and how each one surfaces to an AI client. MetaComp MCP tools are a thin proxy over the MetaComp backend. A successful call returns the tool's payload; a failed call is surfaced to the AI client as a **tool error**. This page documents every response and error shape you can encounter and the recommended handling for each. --- ## How errors reach the AI client Understanding the mechanism first makes the rest of this page easier to handle correctly: - **Success** — the tool returns its payload. Most VisionX and AgentX tools wrap it in a standard success envelope (see below); a few return a bare value or array. - **Failure** — when the backend returns a non-2xx HTTP status, the MCP layer does **not** return a normal payload. Instead the tool result is flagged as an **error result** (`isError`), and the error text is the backend's raw response body — usually a JSON string such as `{"message":"Insufficient credits"}` or `{"success":false,"code":"QUOTE_EXPIRED","message":"..."}`. **Practical consequence for agents:** when a tool call comes back as an error, read the error text — it carries the machine-readable `code`/`message` you need to decide what to do. Do not assume an error result is a transport failure to be blindly retried; most are deliberate business signals (insufficient credits, expired quote, validation failure) that retrying will not fix. --- ## Success wrapper Most VisionX and AgentX tools wrap their payload in a standard success envelope: ```json { "success": true, "code": 200, "msg": "ok", "data": { ... } } ``` | Field | Type | Description | |---|---|---| | `success` | boolean | **The authoritative success signal.** `true` if the operation completed; `false` on a soft failure (see OTC quote below). | | `code` | number | Downstream business status code. Treat `success` — not a specific numeric value — as the source of truth, since the numeric scheme varies by backend subsystem. | | `msg` | string | Human-readable status message. `"ok"` on success; a descriptive string on failure. | | `data` | object or array | The result payload. Shape varies by tool. | When `success` is `false`, read `msg` (and `code` where present) to determine the cause. Do not attempt to parse `data` on a failure response. For VisionX tool-specific response shapes, see [VisionX — Response Reference](/developers/vision-x/responses). For AgentX tool-specific response shapes, see [AgentX — Response Reference](/developers/financial-services/responses). --- ## Re-authentication error shape When a session has expired, or the server cannot authenticate the request, tools return a distinct error object **instead of** the standard success wrapper: ```json { "error": true, "message": "Session expired", "authUrl": "https://www.metacomp.ai/auth/..." } ``` | Field | Type | Description | |---|---|---| | `error` | `true` (literal boolean) | Always `true` on re-authentication errors. | | `message` | string | Human-readable description of why authentication is required. | | `authUrl` | string (optional) | A URL the user must visit to re-authenticate. Present when action is required. | **Handling:** 1. Check whether the response has an `error: true` field before processing the success wrapper. 2. If `authUrl` is present, surface it to the user and prompt them to re-authenticate. Do not silently redirect automated agents. 3. After the user completes authentication, retry the original tool call. 4. If `authUrl` is absent, the error is likely a server-side configuration issue — do not auto-retry. --- ## Credit / metering errors (VisionX KYT) VisionX KYT screening — the `VisionX` tool and the equivalent REST endpoint — is **metered**. Each call draws down a prepaid credit balance on the account. When the balance is too low, or the metering step fails, the call is surfaced as an HTTP error: | HTTP status | Error body | Meaning | Required action | |---|---|---|---| | `402 Payment Required` | `{ "message": "Insufficient credits" }` | The account's credit balance is below the price of this screening call. | **Do not auto-retry** — retrying will not succeed until the account is topped up. Tell the user their VisionX screening credits are exhausted and that they need to add credits (or wait for the next renewal) before screening again. | | `503 Service Unavailable` | `{ "message": "Service temporarily unavailable" }` | The metering/charge step failed transiently (not a balance problem). | Transient. These are safe read-only checks, so a retry with exponential backoff is appropriate. If it persists, surface the failure to the user. | These errors apply only to the two VisionX KYT tools. AgentX (payments / fixed income) tools are not credit-metered and never return `402 Insufficient credits`. > Note: only screenings that actually consume credits can return `402`. Some accounts (e.g. whitelisted ones) and zero-priced operations are not charged and will never hit this path. --- ## OTC quote & trade errors The two-step OTC exchange flow has its own failure modes. They surface in two different ways depending on the step. ### `get_otc_quote` — soft failures (Step 1) `get_otc_quote` returns a normal response with `success: false` (it does **not** raise an HTTP error): ```json { "success": false, "message": "Insufficient USD balance to exchange 100 USDT." } ``` Typical causes are **insufficient balance**, an **unsupported currency pair**, or an **amount above the maximum / below the minimum**. Show `message` to the user, return them to currency selection, and do not auto-retry. Additionally, if `get_otc_quote` succeeds but returns `exchangeRate: ""` or `finalAmount: ""`, the downstream pricing service cannot price that pair at that moment. Do not proceed to `confirm_otc_trade` — inform the user and let them retry later or choose a different pair. ### `confirm_otc_trade` — HTTP errors (Step 2) `confirm_otc_trade` surfaces failures as **HTTP-level errors**, not as `{ "success": false }` payloads. The server re-fetches a fresh quote at confirm time and trades at the live rate, so two conditions can reject the confirmation: | HTTP status | Error body | Meaning | Required action | |---|---|---|---| | `410 Gone` | `{ "success": false, "code": "QUOTE_EXPIRED", "message": "Quote expired or not found, please request a new quote." }` | The 5-minute server-side quote window elapsed before confirmation, or the quote context is gone. | Inform the user the quote has expired. Call `get_otc_quote` again to obtain a fresh quote before proceeding. | | `409 Conflict` | `{ "success": false, "code": "PRICE_DRIFT_EXCEEDED", "message": "Exchange rate moved beyond tolerance (drift=…, tolerance=…), please request a new quote.", "data": { "originalPrice", "newPrice", "tolerance" } }` | The live market rate drifted beyond the system's tolerance from the originally quoted rate. | Inform the user the rate has changed. Call `get_otc_quote` again so they can review the updated rate before confirming. | **Critical:** Do **not** auto-retry on `410` or `409`. Both conditions require the user to explicitly review a new quote. Auto-retrying a destructive financial operation without user review is unsafe. For the full OTC two-step workflow, see [Exchange & OTC](/developers/financial-services/guides/exchange-otc). --- ## Validation errors Requests with missing or malformed parameters are rejected before any business logic runs and surface as an **HTTP 400 Bad Request** tool error, with a message describing the offending field(s). Unknown/extra parameters are stripped rather than rejected. These are caused by the AI client sending arguments that don't match a tool's schema. They are not retryable as-is — correct the arguments (consult the tool's parameter descriptions) and call again. --- ## General error-handling guidance - **Never auto-retry destructive operations.** This includes `confirm_otc_trade`, `execute_fiat_withdrawal`, and `execute_crypto_withdrawal`. If any of these return an error, surface it to the user and wait for explicit confirmation before attempting a new request. - **Don't retry business errors.** `402 Insufficient credits`, `410`/`409` OTC errors, `400` validation errors, and `success: false` soft failures are deliberate signals — retrying without changing something (credits, a fresh quote, corrected arguments) will fail again. - **Retry only transient failures** — e.g. `503`, timeouts, or network errors on safe read operations such as `get_deposit_list` or `VisionX` — and only with exponential backoff. See [Rate Limits](/developers/reference/rate-limits) for backoff guidance. - **Always surface the error message to the user.** MCP tools run in AI client contexts. When a tool returns an error, present its message in plain language rather than silently retrying or swallowing the failure. --- ## Cross-references - [AgentX — Response Reference](/developers/financial-services/responses) — minor units, OTC trade codes, deposit/withdrawal status fields. - [VisionX — Response Reference](/developers/vision-x/responses) — `data` body structure, exposure category enums. - [Rate Limits](/developers/reference/rate-limits) — request cadence guidance and backoff posture. --- # CLI URL: https://www.metacomp.ai/developers/cli > A dedicated MetaComp CLI is coming soon. A dedicated MetaComp command-line tool is **coming soon**. In the meantime, you can already use MetaComp from your terminal through **Claude Code** — Anthropic's official CLI for Claude. See [Claude Code setup](/developers/getting-started/ai-clients/claude-code) to connect MetaComp as an MCP server and run checks via natural language. --- # Changelog URL: https://www.metacomp.ai/developers/resources/changelog > A dated record of significant changes, new tools, and notable updates to the MetaComp MCP API and developer documentation. This changelog records notable changes to the MetaComp MCP API, tools, and developer documentation. Entries are listed newest-first. Routine styling, infrastructure, and build-tooling changes are omitted. --- ## 2026-07-31 **VisionX gets a documented REST surface, a real response contract, and one tool instead of two.** - **VisionX API.** Screening is now available as a direct REST endpoint, `POST /api/v1/transAndWallet`, for backends and services that integrate without an MCP client — see [VisionX — API](/developers/vision-x/api). MCP remains the primary surface; the endpoint returns the same reports as the tool. - **Response Reference, rewritten as a contract.** The page now documents actual fields rather than describing the payload in prose: the success wrapper (`code` is `0`, not `200`), both report bodies, the counterparty breakdown, the exposure arrays, and the per-provider blocks. It also flags the traps — dates are formatted like `12 Sep 2023` rather than ISO 8601, and several numbers and booleans arrive as strings. - **Risk level, not risk score.** Screening returns a categorical level (`Low` / `High` observed) rather than a numeric score, and the high-risk category set is wider than the four categories previously listed. Wording corrected across the VisionX pages; decisions should read `isHighRisk` rather than matching category names. - **One tool, one transaction.** The hosted server exposes VisionX as a single tool, `VisionX`, which screens a wallet, one transaction, or both. Documentation previously described `get_wallet_security` / `get_transaction_security` — those are the tools of the legacy local npm package, now labelled as such. Transaction input is a single `transactionDetail` object; batching several transactions into one billed call is no longer accepted. --- ## 2026-06-03 **Sharper error reference, leaner network docs, and a dark-mode refresh.** - **Status & Errors, expanded.** The reference now documents every failure an agent can encounter in one place — credit/metering limits (`402 Insufficient credits`), the OTC quote and trade errors (`410` quote-expired and `409` rate-drift, with their `code` values), validation errors (`400`), and a new section explaining how each one actually surfaces to an AI client. The goal: an agent should be able to tell a "stop and ask the user" error from a "safe to retry" one without guessing. - **Networks & Currencies retired.** The standalone reference page is gone. Supported networks (Bitcoin, Ethereum, Tron) and currencies are now stated inline where they matter — and, more importantly, the authoritative list is always the one returned at runtime by the `get_*_networks` / `get_*_currencies` tools, never a hard-coded table. - **Dark-mode polish.** Reworked the dark theme for a calmer read: neutral-grey surfaces in place of the previous purple cast, the sidebar sharing the content background, lower-contrast body and heading text, softer card borders and backgrounds, an all-white logo, and a single consistent style for the page toolbar buttons. --- ## 2026-06-02 **Wider AI-client coverage.** - Added a **VS Code** setup guide, bringing the client walkthroughs to seven: Claude.ai, Claude Code, Claude Desktop, Cursor, Windsurf, Cline, and VS Code. - Tightened the Getting Started, Agent Skill, and product pages for accuracy and flow. --- ## 2026-06-01 **Consistent names, clearer navigation, and the Agent Skill.** A broad revision aimed at making the docs faster to scan and the product vocabulary consistent: - **Product names finalized** — **VisionX** (KYT) and **AgentX** (payments + fixed income). The internal PayX / WealthX codenames are gone in favour of plain functional terms; page URLs are unchanged. - **New Agent Skill section** — overview, installation (Claude.ai as the primary path, plus Claude Code, Cursor, and others), and a how-it-works walkthrough. - **Reworked information architecture** — a "two ways to use MetaComp" landing page, a skill-first quickstart, product taglines, and a flatter, tidier sidebar (the CLI now lives under Resources). - **Network vs. currency identifiers** — network fields now use network names (Ethereum, Tron, Bitcoin), with BTC/ETH reserved for currency codes, removing a common source of confusion. - **CLI** — the command reference is now a clearly marked "Coming soon" placeholder while it firms up. - Added a **"Was this page helpful?"** prompt and a social footer, alongside a typography and layout refresh. --- ## 2026-05-31 **Developer documentation launched — VisionX and AgentX.** The MetaComp developer documentation site went live at `/developers`. The initial release covered: - **Getting Started** — quickstart, core concepts, authentication (OAuth 2.0 + PKCE for hosted MCP; direct Bearer token for Claude Code / Claude Desktop), and setup guides for Claude.ai, Claude Code, Claude Desktop, Cursor, Windsurf, and Cline. - **VisionX (KYT)** — concepts, MCP tools (`get_wallet_security`, `get_transaction_security`), response reference, and how-to guides for wallet screening, transaction investigation, and automated compliance pipelines. - **AgentX** — concepts, MCP tools for payments (deposits, withdrawals, OTC) and fixed income (Fixed Income Products), a response reference covering minor-unit conversion and the OTC two-step error model, and a how-to guide for every workflow. - **Reference** — networks and currencies, status and error codes, rate limits and backoff guidance. - **CLI** — Claude Code integration overview and MCP tool command reference. - **Resources** — this changelog, security and compliance overview, FAQ, and support. Built to be read by people and agents alike: client-side full-text search, an `llms.txt` export, and per-page **Copy for LLM**, **View as Markdown**, and **Open in ChatGPT / Claude / Perplexity** actions. --- *New entries will be added here as the API and documentation evolve.* --- # FAQ URL: https://www.metacomp.ai/developers/resources/faq > Answers to frequently asked questions about MetaComp's MCP API, supported clients, networks, authentication, and more. ## Which AI clients are supported? MetaComp works with any MCP-compatible client. Supported and tested clients include: - **Claude.ai** (web) — connects via the hosted MCP URL and OAuth 2.0 + PKCE. - **Claude Code** — connects via a direct Bearer token using `claude mcp add`. - **Claude Desktop** — connects via the local npm package and `--token` flag. - **VS Code** — connects via `mcp.json` using the hosted MCP URL and a Bearer token header. - **Cursor, Windsurf, Cline** — connect via the hosted MCP URL and OAuth 2.0 + PKCE. For setup instructions for each client, see [AI Clients](/developers/getting-started/ai-clients). --- ## Is there a REST API? No. MetaComp's only public integration surface is the MCP server at `https://www.metacomp.ai/mcp`. There is no public REST API, GraphQL API, or WebSocket API. All functionality — KYT checks, financial operations, account queries — is accessed through MCP tools. --- ## Which blockchain networks and currencies are supported? VisionX KYT supports **Bitcoin**, **Ethereum**, and **Tron**. AgentX supports a range of fiat currencies (USD, EUR, GBP, SGD, and others) and crypto currencies (USDT, USDC, BTC, ETH, and others). The exact set available to your account is always queried at runtime via the relevant `get_*_currencies` and `get_*_networks` tools — do not hard-code the lists above. --- ## How does authentication work? Authentication depends on which client you use: - **Claude.ai, Cursor, Windsurf, Cline** — OAuth 2.0 with PKCE. You enter the MCP URL, are redirected to MetaComp's consent page, paste your `sk-…` API key once, and click Allow. The client manages tokens automatically. - **Claude Code** — Direct Bearer token. You pass `--header "Authorization: Bearer YOUR_API_KEY"` when running `claude mcp add`. - **Claude Desktop** — Direct token via the `--token` flag in `claude_desktop_config.json`. - **VS Code** — Direct Bearer token via the `headers` field in `mcp.json`. In all cases, you need a MetaComp API key to authenticate. See [Authentication](/developers/getting-started/authentication) for the full technical details. --- ## How do I get an API key? Log in to the [MetaComp dashboard](https://www.metacomp.ai/dashboard), locate the **API Keys** section, and click **Generate New Key**. Copy the key immediately — it is shown only once. If you lose it, delete that key from the same section and generate a new one. Your API key grants full access to your MetaComp account. Keep it secret; do not commit it to source control or share it in documents or logs. --- ## Do I need to choose a network when running a KYT check? At the MCP tool layer, yes. The `VisionX` tool requires a `network` parameter. In natural-language clients, the AI can often infer the network from the address or transaction format and populate the tool call for you. In direct integrations, do not rely on that inference layer — pass `network` explicitly. --- ## What happens when an OTC quote expires? OTC quotes are valid for a fixed window. If you call `confirm_otc_trade` after the window has elapsed, the server returns HTTP `410 Gone`. If the live rate has drifted from the quoted rate, it returns HTTP `409 Conflict`. In both cases, call `get_otc_quote` again to obtain a fresh quote, and present the updated rate to the user before re-confirming. Do not auto-retry. See [Status & Errors](/developers/reference/status-and-errors) for the full error reference. --- ## Can I auto-retry failed withdrawal or trade operations? No. Destructive financial operations — withdrawals, OTC trade confirmations, FIP subscriptions, and FIP redemptions — must never be auto-retried. If they return an error, surface it to the user and wait for explicit re-confirmation before submitting a new request. See [Rate Limits](/developers/reference/rate-limits) and [Status & Errors](/developers/reference/status-and-errors) for guidance. --- ## Are there rate limits? MetaComp applies rate controls, but specific numeric quotas are not published here. For read-only operations, use exponential backoff on failure. For destructive operations, never auto-retry. If you need higher throughput, contact support. See [Rate Limits](/developers/reference/rate-limits) for details. --- ## Where can I get help? See [Support](/developers/resources/support) for contact channels, the GitHub repository, and what information to include in a request. --- # Security & Compliance URL: https://www.metacomp.ai/developers/resources/security-and-compliance > MetaComp's security posture, data handling practices, KYT methodology, and the safety model around destructive financial operations. This page summarises MetaComp's security posture and the principles governing how the platform handles sensitive data, cryptographic credentials, and high-risk financial operations. --- ## API key security A MetaComp API key (`sk-…`) grants full access to the authenticated user's account. Treat it with the same care as a password. **Best practices:** - Do not commit API keys to source control. Use environment variables or a secrets manager. - Do not share keys in documents, chat messages, or logs. - Issue one key per integration; rotate keys when team members leave or an integration is decommissioned. - Delete a key immediately from the **API Keys** section of the [MetaComp dashboard](https://www.metacomp.ai/dashboard) if you suspect it has been exposed. A replacement key can be generated with no downtime. MetaComp's hosted MCP endpoint (`https://www.metacomp.ai/mcp`) transmits all requests over TLS. API keys are never logged by the MetaComp server in a recoverable form. --- ## Authentication architecture MetaComp's MCP server supports two authentication paths: | Path | Used by | Mechanism | |---|---|---| | OAuth 2.0 + PKCE | Claude.ai, Cursor, Windsurf, Cline | Short-lived access tokens (1 hour); refresh tokens (30 days). Tokens are managed entirely by the client — you never handle them directly. | | Direct Bearer token | Claude Code, Claude Desktop | API key sent as `Authorization: Bearer …` on each request. No expiry; valid until revoked. | Neither path requires storing the raw API key in the client application after initial registration. For the direct Bearer path, the key is stored in the client's MCP server configuration; restrict access to that configuration file appropriately. See [Authentication](/developers/getting-started/authentication) for the full technical description. --- ## KYT methodology VisionX KYT (Know Your Transaction) assessments are produced by aggregating signals from **multiple independent on-chain analytics providers**. Each provider analyses the target wallet or transaction on its own data graph and returns a risk verdict. MetaComp consolidates these per-provider results into a **unified risk verdict** that surfaces both the consensus signal and any significant divergence between providers. Key properties of this methodology: - **Cross-vendor aggregation.** No single data provider's opinion is the sole determinant of the verdict. Relying on multiple vendors reduces false negatives caused by gaps in any one provider's coverage. - **Transparent sourcing.** The per-provider breakdown is included in the response, so you can see where each signal originated. - **On-chain data only.** VisionX analyses publicly available blockchain data. It does not access private user data, off-chain account information, or personal identifiers. Supported networks: Bitcoin, Ethereum, Tron. --- ## Destructive operations require explicit user confirmation Financial operations that are irreversible — withdrawals, OTC trade confirmation, FIP subscriptions and redemptions — are treated as **explicitly user-initiated actions**. MetaComp's MCP tools do not auto-confirm, auto-retry, or chain destructive operations without user input. The following tools must only be called after the user has reviewed and explicitly approved the action: - `execute_fiat_withdrawal` - `execute_crypto_withdrawal` - `confirm_otc_trade` - `subscribe_fip` - `redeem_fip` If a destructive tool returns an error, the correct response is to surface the error to the user and wait for re-confirmation — not to retry silently. See [Status & Errors](/developers/reference/status-and-errors) for error shapes and [Rate Limits](/developers/reference/rate-limits) for the no-auto-retry policy. --- ## Data handling MetaComp processes the minimum data necessary to fulfil each request. For KYT checks, only the wallet address or transaction hash you supply is processed — no off-chain personal data is required or collected. For AgentX operations, account and transaction data is handled in accordance with MetaComp's privacy policy and applicable financial regulations in the jurisdictions in which MetaComp operates. MetaComp does not make specific claims about certifications (such as SOC 2 or ISO 27001) in this document. For current compliance status, certification scope, and data residency details, contact the MetaComp team through the channels listed on the [Support](/developers/resources/support) page. --- ## Responsible disclosure If you discover a security vulnerability in MetaComp's platform or API, please report it responsibly via the contact channels on the [Support](/developers/resources/support) page rather than disclosing it publicly. Include a clear description of the issue, steps to reproduce, and potential impact. --- # Support URL: https://www.metacomp.ai/developers/resources/support > How to get help with MetaComp's MCP API, report bugs, request higher throughput, or ask questions about VisionX and AgentX. ## GitHub For issues related to the open-source MetaComp skill package, workflow instructions, or documentation wording, open an issue or start a discussion in the GitHub repository: **[https://github.com/metacomp-ai/metacomp-skill](https://github.com/metacomp-ai/metacomp-skill)** When filing an issue, include: - A description of what you were trying to do. - The tool name and, if applicable, the error shape you received (omit sensitive data such as wallet addresses, account numbers, or API keys). - The AI client and version you are using. - Steps to reproduce the problem. --- ## General inquiries and API support For questions not covered by the documentation — account setup, billing, API access, throughput increases, or integration guidance — contact the MetaComp team through the **MetaComp website** at [https://www.metacomp.ai](https://www.metacomp.ai) or via the contact details listed in your dashboard. When contacting support, include: - A clear description of your question or issue. - Your account identifier or the email address on your MetaComp account (do not include your API key). - Relevant error messages or response payloads (with sensitive fields redacted). --- ## Requesting higher throughput MetaComp does not publish specific rate-limit quotas. If your integration requires throughput beyond what the standard configuration allows, reach out via the channels above and describe your use case. See [Rate Limits](/developers/reference/rate-limits) for the general posture. --- ## Security vulnerabilities If you discover a security vulnerability in MetaComp's platform, API, or documentation, please report it responsibly through the contact channels above rather than disclosing it publicly. For more details on MetaComp's security posture, see [Security & Compliance](/developers/resources/security-and-compliance). --- ## Documentation feedback If you find an error, an ambiguity, or a gap in the documentation, open an issue in the [GitHub repository](https://github.com/metacomp-ai/metacomp-skill) with the affected page, the incorrect wording, and the suggested replacement. For account-specific or production-behavior issues, contact MetaComp support instead of filing a public issue.