> ## Documentation Index > Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Remote MCP Server > Connect AI clients to a running CData Arc instance through the built-in Model Context Protocol (MCP) server for diagnostics and operational actions. CData Arc includes a built-in **MCP server** that lets you connect AI clients (such as Claude Desktop, GitHub Copilot, OpenAI Codex, or any MCP-compatible client) directly to a running Arc instance. You can then interact with Arc in natural language to ask about errors, logs, configurations, connectors, files, certificates, and overall system health, and to perform operational actions such as triggering connectors and requeuing messages. The MCP server is enabled by default. It exposes 18 tools: 15 diagnostic tools and 3 action tools that perform operations on your Arc instance. You do not need to configure anything in the Arc UI; the feature is the MCP server endpoint itself, which external AI clients connect to. > [!WARNING] > > The MCP server exposes Arc data to an AI client, and AI-generated responses can be incomplete or inaccurate. Treat the diagnoses, summaries, and suggestions you receive as a starting point rather than a definitive answer, and verify anything important against Arc directly before acting on it. If you are still experiencing issues after using the MCP server, open a ticket with {companyName} Support at \[[arcsupport@cdata.com](mailto:arcsupport@cdata.com)]\(mailto:[arcsupport@cdata.com](mailto:arcsupport@cdata.com)). To configure Arc's own AI provider (for in-product AI features), see [AI Settings](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/ai-settings.md) instead. ## Connecting an AI Client The MCP server endpoint is available at: ``` https://:/mcp.rsc ``` Authentication uses the `x-cdata-authtoken` header with a valid Arc user authtoken. To generate an authtoken, check **Enable Authtoken Access** on the **API Access** tab for your user on the [User Roles](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/user-roles.md) page and copy the system-generated authtoken. ### Storing Your Authtoken Securely The client configuration examples below include the authtoken as an inline value in the config file. This works, but config files on a shared workstation can be read by other local users or accidentally committed to version control. Storing the token in an OS environment variable keeps it out of the config file itself. **Linux and macOS** Add the following line to your shell profile (`~/.bashrc`, `~/.zshrc`, or `~/.profile`) and reload it: ```bash theme={null} export ARC_AUTHTOKEN="your-authtoken" ``` **Windows** Open a command prompt and run: ``` setx ARC_AUTHTOKEN "your-authtoken" ``` This sets a persistent user-level environment variable. Restart any open terminals or applications after running the command so they pick up the new variable. #### Referencing the variable in client config files Both the **GitHub Copilot CLI** and **OpenAI Codex** clients are launched from a terminal and inherit the full system environment, so they can read directly from system environment variables. The secure configuration for each is shown in its section below. **Claude Desktop** does not inherit the full system environment the way a terminal-launched process does, so environment variable references in its config JSON do not work. Use the `--header-file` approach described in the [Claude Desktop](#claude-desktop) section below instead. After saving one of the following configurations, restart your AI client session. ### Claude Desktop Claude Desktop communicates with MCP servers over `stdio` (it launches a local subprocess and talks over `stdin/stdout`), so it cannot connect directly to Arc's remote HTTP endpoint. The `mcp-remote` npm package bridges this gap: it runs as a local stdio process that Claude Desktop talks to, and forwards requests to Arc's HTTP endpoint. The `--transport http-only` flag tells `mcp-remote` to use plain streamable HTTP when communicating with Arc, which skips any attempt to negotiate SSE (Server-Sent Events). The `mcp.rsc` endpoint does not support SSE, so this flag avoids unnecessary fallback delays or connection errors. Add the following to the Claude Desktop config file (**Settings > Developer > Edit Config**): ```json theme={null} { "mcpServers": { "arc-mcp": { "command": "npx", "args": ["-y", "mcp-remote", "https://:/mcp.rsc", "--transport", "http-only", "--header", "x-cdata-authtoken:"] } } } ``` > [!NOTE] > > If you use Windows, use `"command": "cmd"` and add the `"cmd", "/c"` prefix before `"npx"`. #### Alternative token reference with `--header-file` Claude Desktop's config JSON does not support environment variable references because no shell is involved when it launches the subprocess. To keep the authtoken out of the config file, use the `mcp-remote` `--header-file` flag instead. Create a plain text file anywhere Claude Desktop can access it (such as `/home//.cdata/arc-mcp-headers.txt`). Add the following line: ``` x-cdata-authtoken: ``` Then restrict the file so only your user account can read it: **macOS and Linux**: ```bash theme={null} chmod 600 /home//.cdata/arc-mcp-headers.txt ``` **Windows** (command prompt): ``` icacls "C:\Users\\.cdata\arc-mcp-headers.txt" /inheritance:r /grant:r "%USERNAME%:R" ``` Then update the config to use `--header-file` instead of `--header`: ```json theme={null} { "mcpServers": { "arc-mcp": { "command": "npx", "args": ["-y", "mcp-remote", "https://:/mcp.rsc", "--transport", "http-only", "--header-file", "/home//.cdata/arc-mcp-headers.txt"] } } } ``` > [!NOTE] > > If you use Windows, use `"command": "cmd"`, add the `"cmd", "/c"` prefix before `"npx"`, and use a Windows path such as `C:\Users\\.cdata\arc-mcp-headers.txt` (in JSON strings, use \ for each backslash). After saving, quit and reopen Claude Desktop, then enable the `arc-mcp` server in the **Tools/Search** menu of a new chat. ### GitHub Copilot CLI Unlike Claude Desktop, the GitHub Copilot CLI connects to remote MCP servers directly over HTTP, so it does not need a `mcp-remote` bridge; instead, you point it straight at the Arc endpoint. Its MCP config file location depends on your OS: | OS | Config file location | | - | - | | macOS / Linux | `~/.copilot/mcp-config.json` | | Windows | `C:\Users\\.copilot\mcp-config.json` | Edit the file and add the following: ```json theme={null} { "mcpServers": { "arc-mcp": { "url": "https://:/mcp.rsc", "type": "http", "headers": { "x-cdata-authtoken": "" } } } } ``` #### Secure token storage with an environment variable GitHub Copilot CLI supports `${VAR}` substitution in the `headers` field. Replace the inline authtoken value with a reference to the `ARC_AUTHTOKEN` variable: ```json theme={null} { "mcpServers": { "arc-mcp": { "url": "https://:/mcp.rsc", "type": "http", "headers": { "x-cdata-authtoken": "${ARC_AUTHTOKEN}" } } } } ``` `ARC_AUTHTOKEN` must be set as a system or user environment variable before launching Copilot CLI. See [Storing Your Authtoken Securely](#storing-your-authtoken-securely) for setup instructions. After saving, start a new Copilot CLI session so it picks up the `arc-mcp` server. ### OpenAI Codex Like the Copilot CLI, OpenAI Codex supports remote HTTP MCP servers directly, so you do not need a bridge; it connects straight to the Arc endpoint. Its config file location depends on your OS: | OS | Config file location | | - | - | | macOS / Linux | `~/.codex/config.toml` | | Windows | `C:\Users\\.codex\config.toml` | This configuration is shared across the Codex CLI, the Codex IDE extension, and Codex Desktop. Edit the file and add the following: ```toml theme={null} [mcp_servers.arc-mcp] url = "https://:/mcp.rsc" http_headers = { "x-cdata-authtoken" = "" } ``` #### Secure token storage with an environment variable OpenAI Codex has a separate `env_http_headers` field that maps a header name to an environment variable name rather than an inline value. Replace `http_headers` with `env_http_headers`: ```toml theme={null} [mcp_servers.arc-mcp] url = "https://:/mcp.rsc" env_http_headers = { "x-cdata-authtoken" = "ARC_AUTHTOKEN" } ``` `ARC_AUTHTOKEN` must be set as a system or user environment variable before launching Codex. See [Storing Your Authtoken Securely](#storing-your-authtoken-securely) for setup instructions. After saving, restart Codex (or start a new session) so it loads the `arc-mcp` server. ## Correlation Ids Arc stamps a correlation Id on the work that starts at a single entry point (an inbound HTTP request, an AS2 or SFTP session, a scheduled trigger, or a Flow API call) and carries it through to the resulting transactions, application log entries, request log entries, and service log sessions. Several diagnostic tools below return this Id when available, letting you tie related evidence together for the same unit of work. ## Available Tools ### Diagnostic Tools The following 15 tools are read-only and do not modify any data or state on your Arc instance.
Tool Description
`find_workspaces`List and inspect Arc workspaces, including connector summaries and recent transaction and error counts.
`find_connectors`Browse connectors by workspace or type; drill into a connector's configuration, flow connections, referenced certificates, and error rate.
`find_messages`Search transaction messages by connector, status, direction, time range, or message Id. Retrieve message detail including headers and transaction log content.
`find_files`Search connector message files in Send, Receive, or Sent folders. Retrieve file content by name.
`find_logs`Query application logs by severity level, time range, or message text. Returns a correlation Id field when one is available, which links log entries to related transactions and service log sessions.
`find_requests`Inspect API request logs for auditing and troubleshooting (filter by method, URL, user, IP, or time range). Returns a correlation Id field when one is available.
`find_certificates`Find certificates, check expiration dates, and filter by connector usage or category (Public or Private).
`find_vault_entries`Search vault entries by name, type, or tags. Encrypted values are never exposed.
`find_reports`Browse report definitions and inspect schedule, column, filter, and email recipient configuration.
`find_flow_apis`Explore Flow API definitions or get an API's request and response configuration.
`find_service_logs`Find connector service logs (AS2, AS4, GISB, RNIF, FTP Server, OFTP, SFTP Server, TCP Server, AMQP, IDoc, MQTT) and retrieve the content of one log. Useful for connection, listener, and protocol-level failures that did not produce a transaction record.
`diagnose_message`Diagnose a specific transaction message by its message Id or transaction Id. Returns the full message detail (headers and transaction log content). When a correlation Id is present, also returns the related request log entries, application log entries, and service log evidence for that message.
`trace_message_flow`Trace a message end-to-end as it moves across connectors in a flow, when given a message Id or a filename plus connector.
`check_health`Get a health snapshot of the Arc instance: error counts, expiring certificates, license status, memory and disk warnings, and per-connector failure rates and message backlogs.
`describe_profile`View Arc profile settings (Application, AS2, SFTP, and so on) grouped by section. Secret values are masked.
### Action Tools Three of the 18 tools perform real operations on your Arc instance rather than just reading data. Before any of these tools runs, the AI client requests your explicit confirmation. The following guardrails apply to all three: * **Confirmation required.** The AI client cannot perform an action without explicit confirmation from you first. * **Existing permissions apply.** Users can only trigger, requeue, or clean up resources their Arc permissions already allow. Users with read-only access cannot invoke action tools at all. * **Targets must be named.** Every action specifies the exact workspace and connector it affects. Nothing is inferred or guessed. * **Actions are audited.** Each operation writes an audit record identifying what ran, against which connector, and the outcome. See [User Roles](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/user-roles.md) to review or adjust permissions.
Tool Description
`trigger_connector`Run a connector's receive or send operation, optionally targeting a specific file or message.
`requeue_message`Requeue a previously processed message so the connector processes it again, equivalent to the **Requeue** action on the **Transactions** tab.
`cleanup_files`Run the [configured bulk cleanup](https://docs.arc.cdata.com/26.4/cloud/en/getting-started/administration/settings/cleanup-settings.md), archiving or deleting data older than a given number of days, for one connector, one workspace, or all workspaces.
## Example Prompts You interact with Arc through your AI client in natural language. Example diagnostic prompts include: * "Analyze the failure for message EDIFACT1-20260513-123047000-wxcU and provide suggestions on how to fix it." * "Show me all error logs from the last 24 hours that mention AS2." * "What certificates are expiring within the next 30 days?" * "Trace message AS2\_Inbound-20260623-001 across its flow." * "Check the health of the production workspace." * "List all SFTP connectors." * "Show me the SFTP Server service log for sessions from this morning." For action tools, the AI client requests your confirmation before proceeding. For example: * **You:** Requeue message AS2\_Outbound-20260814-001 on the AS2\_Outbound connector in the Production workspace. * **AI client:** I will requeue message AS2\_Outbound-20260814-001 on the AS2\_Outbound connector in the Production workspace. This will cause the connector to process the message again. Do you want to proceed? * **You:** Yes. * **AI client:** Done. The message has been requeued. ## Security Notes * The MCP server respects Arc's existing authentication and authorization. Users only see data they have permission to access. * Always connect over HTTPS. The `x-cdata-authtoken` is sent in a request header on every call; over plain HTTP it is exposed in transit. Only use `http://` when testing against `localhost`. * Sensitive values (passwords, tokens, and private keys) are masked in tool responses. * Encrypted vault entry values are never returned. * Store your authtoken in an OS environment variable rather than as an inline value in the client config file. See [Storing Your Authtoken Securely](#storing-your-authtoken-securely). * Action tools require explicit user confirmation before any operation runs, and every action is audited. Users with read-only access cannot invoke action tools. ## Known Limitations in this Release * Large message payloads returned in detail mode can be sizable, which might affect token usage in AI clients. * Service logs are retrieved per session. When a session covers multiple files, the correlated evidence returned by `diagnose_message` can include other files from the same session. This is expected behavior. * Correlation Ids cover the main message-processing paths. Some paths, such as certain scheduled retry workers, might not carry a correlation Id. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.