Skip to content

MCP Server

This document is intended for external users and explains how to configure the information publishing system's MCP Server in AI agents that support MCP.

Through MCP, agents can read information publishing system data within the user's authorized scope and call automation capabilities provided by the system. This can be used for workflows such as device inspection, program lookup, deployment verification, device binding, issue diagnosis, and dynamic control. Its goal is not to replace the admin interface, but to let agents use natural language and automated plans to handle repetitive queries, batch verification, and remote control assistance.

Start with Cloud HTTP MCP

Cloud HTTP MCP is the simplest way to get started — the cloud MCP server is already running, so you just need to configure your agent. No additional installation or services required. The source is fixed to cloud mode. Once you're familiar with it, you can explore advanced configurations like in-app MCP, stdio MCP, or Docker deployment.

What You Can Do

The MCP Server is designed for automation control scenarios in the information publishing system. After an agent connects, it can work within the permission scope of the currently logged-in user to:

  • View the current connection context, including data source, user, tenant, and customer scope.
  • Query visible devices, programs, assets, groups, and deployment relationships.
  • Read device status, program details, entity attributes, and programs currently associated with a device.
  • Help complete management workflows such as device binding, activation code lookup, and activation.
  • Combine the agent's planning and conversational capabilities to perform automated workflows such as batch inspection, status verification, remote deployment checks, and dynamic control suggestions.

The MCP Server does not bypass system permissions. All requests are executed using the configured login token and source context, so different users can only access data and operations they are authorized to use.

The cloud MCP server is already running. You just need to get a token and configure your agent — no additional installation or services required. Cloud HTTP MCP uses cloud source only. The whole process takes two steps: get a token → configure your agent.

Prerequisites

  • A valid management app account.
  • An MCP-compatible agent such as Claude Code or Codex installed.

Compatibility

MCP Server is supported in recent versions of the management app. If your management app is older, please upgrade first. On the agent side, we recommend using the latest version of Claude Code or Codex.

Step 1: Get Your JWT Token

Log in to the management app (Web or desktop client), click your user avatar, and select "Copy Token".

This Token is your identity credential for MCP connections. Keep it safe — do not share it or commit it to code repositories.

Step 2: Configure Your Agent

Claude Code

bash
export CX_MCP_TOKEN='<your-jwt>'

claude mcp add --transport http \
  cx-cloud http://127.0.0.1:9394/mcp \
  --header "Authorization: Bearer $CX_MCP_TOKEN" \
  --header "X-Mht-Source-Key: cloud"

Codex

Edit ~/.codex/config.toml:

toml
[mcp_servers.cx_cloud]
url = "http://127.0.0.1:9394/mcp"
bearer_token_env_var = "CX_MCP_TOKEN"
http_headers = { "X-Mht-Source-Key" = "cloud" }

Set the environment variable before launching Codex:

bash
export CX_MCP_TOKEN='<your-jwt>'
codex

Codex Version Note

The bearer_token_env_var field is supported in newer versions of Codex. If your Codex version does not support it, use http_headers to pass Authorization: Bearer <jwt> directly, or upgrade Codex to the latest version.

Verify the Connection

Check the MCP connection status in your agent:

bash
# Claude Code
claude mcp list
claude mcp get cx-cloud

# Inside Claude Code, run
/mcp
bash
# Codex
codex mcp list
codex mcp get cx_cloud

Confirm that cx-cloud is connected and you can see the tools. You can then try asking in the conversation:

  • "List all my devices"
  • "Check the current program on this device"
  • "Which devices is this program deployed to?"

Quick Start ends here

The Quick Start above covers the needs of most users. The sections below cover Token internals, LAN intranet mode, stdio, Docker, and other advanced configurations for users with specific requirements.

Token and Source

The quick start above uses Cloud source (online mode), which is the default for most users. If you need to use MCP in an intranet or offline environment, you'll need to understand LAN source.

Two Source Types

CloudLAN
Use caseDevices can access the internet, remote managementDevices cannot access the internet, intranet/offline
Token sourceCloud account JWT from management app loginLAN JWT from management app's local service
PrerequisiteNone (connects directly to cloud)Enable local service in management app
Activation code / MHActivation toolsAvailable directlyRequires additional cloud account JWT

Cloud Source HTTP Headers

text
Authorization: Bearer <jwt>
X-Mht-Source-Key: cloud

LAN Source HTTP Headers

text
Authorization: Bearer <lan-jwt>
X-Mht-Source-Key: lan
X-Mht-Lan-Host: http://127.0.0.1:9393

Some cloud features (such as activation code / MHActivation tools) require a cloud account. When using LAN source, you need to provide an additional cloud account JWT for these features:

text
X-Mht-Cloud-Authorization: Bearer <cloud-jwt>

It is recommended to pass tokens via environment variables and never commit JWTs to repositories or shared configurations.

Advanced Configuration

The following methods are suitable after you're familiar with Cloud HTTP MCP and need more specific setups. For example: using LAN source in an intranet/offline environment, letting the agent launch MCP on demand, or deploying via Docker.

In-App HTTP MCP

Platform Support

In-app MCP is supported on management and player apps for Android, Windows, and Linux (requires a recent version). If you cannot find the "Local Services" screen, please upgrade the app first.

In the management or player app, go to the "Local Services" screen and turn on the MCP service switch. Once enabled, the interface will display something like:

text
http://192.168.1.10:9394/mcp

Agents on the same LAN should use this address to connect. Do not configure the in-app MCP as 127.0.0.1 unless the agent and the app are running on the same device.

stdio MCP

stdio MCP is suitable for agents like Claude Code and Codex to launch the cxmcp_stdio executable directly, without needing a persistent HTTP service. cxmcp_stdio is also included in the management app installation package.

Cloud mode:

bash
CX_MCP_TOKEN='<jwt>' /path/to/cxmcp_stdio \
  --source cloud \
  --token-env CX_MCP_TOKEN

LAN mode:

bash
CX_MCP_TOKEN_LAN='<lan-jwt>' /path/to/cxmcp_stdio \
  --source lan \
  --token-env CX_MCP_TOKEN_LAN \
  --lan-host http://127.0.0.1:9393

When using LAN source and needing activation code / MHActivation tools, provide an additional cloud account token:

bash
CX_MCP_TOKEN_LAN='<lan-jwt>' CX_MCP_CLOUD_TOKEN='<cloud-jwt>' /path/to/cxmcp_stdio \
  --source lan \
  --token-env CX_MCP_TOKEN_LAN \
  --cloud-token-env CX_MCP_CLOUD_TOKEN \
  --lan-host http://127.0.0.1:9393

Docker stdio MCP

The Docker version of cxmcp_stdio can replace native executable installation. It is still a stdio MCP and must be run with docker run -i — do not use -d, and no port mapping is required. Replace <cxmcp-stdio-image> with the actual image name provided by your OEM or deployment environment.

Cloud:

bash
docker run -i --rm \
  -e CX_MCP_TOKEN='<jwt>' \
  <cxmcp-stdio-image> \
  --source cloud \
  --token-env CX_MCP_TOKEN

LAN:

bash
export CX_MCP_LAN_HOST='http://host.docker.internal:9393'

docker run -i --rm \
  -e CX_MCP_TOKEN_LAN='<lan-jwt>' \
  -e CX_MCP_CLOUD_TOKEN='<cloud-jwt>' \
  <cxmcp-stdio-image> \
  --source lan \
  --token-env CX_MCP_TOKEN_LAN \
  --cloud-token-env CX_MCP_CLOUD_TOKEN \
  --lan-host "$CX_MCP_LAN_HOST"

On Docker Desktop (macOS/Windows), containers accessing the host's local service should use host.docker.internal instead of 127.0.0.1. On Linux Docker without host.docker.internal, add the following when running:

bash
--add-host=host.docker.internal:host-gateway

Claude Code Full Configuration

If the token, source, or LAN host changes, it is recommended to remove the old configuration first, then re-add it to avoid stale headers or environment variables:

bash
claude mcp remove cx-cloud -s local
claude mcp remove cx-lan -s local
claude mcp remove cx-cloud-stdio -s local
claude mcp remove cx-lan-stdio -s local

HTTP Cloud

bash
export CX_MCP_TOKEN='<jwt>'

claude mcp add --transport http \
  cx-cloud http://127.0.0.1:9394/mcp \
  --header "Authorization: Bearer $CX_MCP_TOKEN" \
  --header "X-Mht-Source-Key: cloud"

HTTP LAN

bash
export CX_MCP_TOKEN_LAN='<lan-jwt>'
export CX_MCP_CLOUD_TOKEN='<cloud-jwt>'
export CX_MCP_LAN_HOST='http://127.0.0.1:9393'

claude mcp add --transport http \
  cx-lan http://127.0.0.1:9394/mcp \
  --header "Authorization: Bearer $CX_MCP_TOKEN_LAN" \
  --header "X-Mht-Source-Key: lan" \
  --header "X-Mht-Lan-Host: $CX_MCP_LAN_HOST" \
  --header "X-Mht-Cloud-Authorization: Bearer $CX_MCP_CLOUD_TOKEN"

X-Mht-Cloud-Authorization is only needed when the LAN source requires access to cloud account features. It can be omitted for regular LAN device/program queries.

stdio Cloud

bash
claude mcp add cx-cloud-stdio \
  -e CX_MCP_TOKEN='<jwt>' \
  -- /path/to/cxmcp_stdio --source cloud --token-env CX_MCP_TOKEN

stdio LAN

bash
claude mcp add cx-lan-stdio \
  -e CX_MCP_TOKEN_LAN='<lan-jwt>' \
  -e CX_MCP_CLOUD_TOKEN='<cloud-jwt>' \
  -- /path/to/cxmcp_stdio \
    --source lan \
    --token-env CX_MCP_TOKEN_LAN \
    --cloud-token-env CX_MCP_CLOUD_TOKEN \
    --lan-host http://127.0.0.1:9393

You can also put the LAN host in an environment variable:

bash
export CX_MCP_LAN_HOST='http://127.0.0.1:9393'

claude mcp add cx-lan-stdio \
  -e CX_MCP_TOKEN_LAN='<lan-jwt>' \
  -e CX_MCP_CLOUD_TOKEN='<cloud-jwt>' \
  -- /path/to/cxmcp_stdio \
    --source lan \
    --token-env CX_MCP_TOKEN_LAN \
    --cloud-token-env CX_MCP_CLOUD_TOKEN \
    --lan-host "$CX_MCP_LAN_HOST"

Codex Full Configuration

Codex uses ~/.codex/config.toml to configure MCP servers. HTTP MCP can use url, and stdio MCP can use command/args/env.

If the source or LAN host changes, it is recommended to delete the corresponding [mcp_servers.<name>] block from ~/.codex/config.toml, then rewrite it.

HTTP Cloud

toml
[mcp_servers.cx_cloud]
url = "http://127.0.0.1:9394/mcp"
bearer_token_env_var = "CX_MCP_TOKEN"
http_headers = { "X-Mht-Source-Key" = "cloud" }

Set the environment variable before launching Codex:

bash
export CX_MCP_TOKEN='<jwt>'
codex

HTTP LAN

toml
[mcp_servers.cx_lan]
url = "http://127.0.0.1:9394/mcp"
bearer_token_env_var = "CX_MCP_TOKEN_LAN"
http_headers = { "X-Mht-Source-Key" = "lan", "X-Mht-Lan-Host" = "http://127.0.0.1:9393", "X-Mht-Cloud-Authorization" = "Bearer <cloud-jwt>" }

If you prefer not to write the cloud account JWT into config.toml, you can omit X-Mht-Cloud-Authorization for now, or use stdio MCP to pass CX_MCP_CLOUD_TOKEN via env.

stdio Cloud

toml
[mcp_servers.cx_cloud_stdio]
command = "/path/to/cxmcp_stdio"
args = ["--source", "cloud", "--token-env", "CX_MCP_TOKEN"]
env = { "CX_MCP_TOKEN" = "<jwt>" }

stdio LAN

toml
[mcp_servers.cx_lan_stdio]
command = "/path/to/cxmcp_stdio"
args = ["--source", "lan", "--token-env", "CX_MCP_TOKEN_LAN", "--cloud-token-env", "CX_MCP_CLOUD_TOKEN", "--lan-host", "http://127.0.0.1:9393"]
env = { "CX_MCP_TOKEN_LAN" = "<lan-jwt>", "CX_MCP_CLOUD_TOKEN" = "<cloud-jwt>" }

To switch the LAN host, simply change the value of --lan-host. Note that Codex args do not perform shell variable expansion, so do not write $CX_MCP_LAN_HOST here — use the actual address.

Docker stdio Cloud

toml
[mcp_servers.cx_cloud_stdio_docker]
command = "docker"
args = [
  "run", "-i", "--rm",
  "-e", "CX_MCP_TOKEN",
  "<cxmcp-stdio-image>",
  "--source", "cloud",
  "--token-env", "CX_MCP_TOKEN"
]
env = { "CX_MCP_TOKEN" = "<jwt>" }

Docker stdio LAN

toml
[mcp_servers.cx_lan_stdio_docker]
command = "docker"
args = [
  "run", "-i", "--rm",
  "--add-host=host.docker.internal:host-gateway",
  "-e", "CX_MCP_TOKEN_LAN",
  "-e", "CX_MCP_CLOUD_TOKEN",
  "<cxmcp-stdio-image>",
  "--source", "lan",
  "--token-env", "CX_MCP_TOKEN_LAN",
  "--cloud-token-env", "CX_MCP_CLOUD_TOKEN",
  "--lan-host", "http://host.docker.internal:9393"
]
env = { "CX_MCP_TOKEN_LAN" = "<lan-jwt>", "CX_MCP_CLOUD_TOKEN" = "<cloud-jwt>" }

Verify and remove:

bash
codex mcp list
codex mcp get cx_lan

# Remove
codex mcp remove cx_cloud
codex mcp remove cx_lan
codex mcp remove cx_cloud_stdio
codex mcp remove cx_lan_stdio

If your current Codex version does not have the mcp remove command, you can directly edit ~/.codex/config.toml and delete the corresponding configuration block.

Other Agents

If your agent is not listed above, you can use the following general configuration parameters.

Agents Supporting Streamable HTTP MCP

General HTTP parameters:

  • URL: http://127.0.0.1:9394/mcp
  • Header: Authorization: Bearer <jwt>
  • Cloud Header: X-Mht-Source-Key: cloud
  • LAN Header: X-Mht-Source-Key: lan
  • LAN Header: X-Mht-Lan-Host: http://127.0.0.1:9393
  • LAN Optional Cloud Header: X-Mht-Cloud-Authorization: Bearer <cloud-jwt>

Cursor example (configure in ~/.cursor/mcp.json):

json
{
  "mcpServers": {
    "cx-cloud": {
      "url": "http://127.0.0.1:9394/mcp",
      "headers": {
        "Authorization": "Bearer <jwt>",
        "X-Mht-Source-Key": "cloud"
      }
    }
  }
}

Agents Supporting stdio MCP

General stdio parameters:

  • Command: /path/to/cxmcp_stdio
  • Cloud args: --source cloud --token-env CX_MCP_TOKEN
  • LAN args: --source lan --token-env CX_MCP_TOKEN_LAN --cloud-token-env CX_MCP_CLOUD_TOKEN --lan-host http://127.0.0.1:9393
  • Cloud Env: CX_MCP_TOKEN=<jwt>
  • LAN Env: CX_MCP_TOKEN_LAN=<lan-jwt>
  • LAN Optional Env: CX_MCP_CLOUD_TOKEN=<cloud-jwt>
  • The LAN host can be placed in your own environment variable, but the startup argument must still be passed explicitly: --lan-host "$CX_MCP_LAN_HOST"
  • Docker Command: docker
  • Docker args: run -i --rm -e CX_MCP_TOKEN <cxmcp-stdio-image> --source cloud --token-env CX_MCP_TOKEN

Frequently Asked Questions

Connection failures or tool call errors

Check:

  • Whether the token has expired.
  • Whether HTTP mode is using the Authorization: Bearer <jwt> format.
  • Whether the token belongs to the current source.
  • Whether LAN mode has X-Mht-Source-Key: lan and X-Mht-Lan-Host configured.
  • Whether stdio LAN has --lan-host configured, or whether it is explicitly passed via --lan-host "$CX_MCP_LAN_HOST" in shell examples.
  • Whether, when using LAN source to call activation code / MHActivation tools, an additional cloud account token has been configured: HTTP via X-Mht-Cloud-Authorization, stdio via CX_MCP_CLOUD_TOKEN.

Tools list is empty

  • Confirm that the MCP service address in the agent configuration is correct.
  • Reconnect the MCP Server in the agent (e.g., run /mcp again in Claude Code).
  • Check if the token is valid: an expired or invalid token may result in an empty tools list without an explicit error.

Token expiration

The current version does not support refresh tokens. After a token expires, you need to obtain a new JWT and update the agent configuration. Common symptoms:

  • Tools that previously worked suddenly return permission or authentication errors.
  • The agent reports that the MCP Server connection has dropped.

After obtaining a new token, update the JWT value in the environment variable or agent configuration.

HTTP MCP port already in use

If you are running MCP locally and port 9394 is occupied by another program, you can customize the port:

bash
cxmcp_http --port=9395

Then update the port in the agent configuration URL accordingly. This does not apply when using Cloud HTTP MCP.

Configuration changes not taking effect

Remove the old MCP server first, then reconfigure. This is especially important when the source, LAN host, or command path changes — overwriting is not recommended.

Using LAN and Cloud simultaneously

It is recommended to configure them as two separate MCP servers, for example:

  • cx_cloud
  • cx_lan

They can use the same HTTP MCP URL but require different tokens and source configurations.

Security Notes

  • Do not commit JWTs to repositories. Use .env files or environment variables, and add .env to .gitignore.
  • For local testing, prefer environment variables or local private configuration files.
  • HTTP MCP binds to 127.0.0.1 by default — do not casually expose it to the public internet.
  • For stdio mode, it is recommended to use the CX_MCP_TOKEN environment variable to pass the token; --token is only recommended for temporary debugging.
  • The LAN source's CX_MCP_CLOUD_TOKEN is a cloud account JWT and must also not be committed to repositories or shared configurations.
  • The current version does not support refresh tokens; you will need to provide a new JWT after the token expires.