Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/davidpastorvicente/mcpx-cli/llms.txt

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

After your initial MCPX setup, you manage your server roster through a handful of focused commands. Every mutation command — add, remove, enable, disable — automatically reads .agents/mcp.json, applies the change, and regenerates all provider config files so everything stays in sync without any extra steps.
Do not manually edit provider config files such as .mcp.json, .copilot/mcp-config.json, or .vscode/mcp.json. MCPX overwrites them every time it syncs. Make all changes through .agents/mcp.json or MCPX commands.

Adding a server

Use mcpx add to launch the interactive server wizard:
mcpx add jira
The name argument is optional and is only used to detect a duplicate early — the wizard always prompts you for the server name. The wizard walks you through:
  1. Server name — a short identifier (letters, numbers, hyphens, dots, and underscores)
  2. Transport typestdio (local command) or http (remote URL)
  3. Command (stdio) — the executable to run, e.g. uvx, npx, docker
  4. Arguments (stdio) — comma-separated args passed to the command
  5. Environment variables (stdio) — key/value pairs for the server process
  6. URL (http) — the remote server endpoint
  7. Headers (http) — key/value pairs sent with every request
After you confirm, MCPX writes the new server to .agents/mcp.json and updates all provider files. The new entry looks like this:
"jira": {
  "enabled": true,
  "transport": "stdio",
  "command": "uvx",
  "args": ["mcp-atlassian"],
  "env": {
    "JIRA_API_TOKEN": "your-token",
    "JIRA_URL": "https://myorg.atlassian.net",
    "JIRA_USERNAME": "user@example.com"
  }
}
If you try to add a server whose name already exists in .agents/mcp.json, MCPX will warn you and abort. Either choose a different name or remove the existing entry first.

Temporarily disabling a server

Disabling a server keeps its configuration in .agents/mcp.json but tells MCPX to omit it from all generated provider files. This is useful when you want to pause a server without losing its settings.
mcpx disable jira
MCPX sets "enabled": false in .agents/mcp.json and regenerates all provider files immediately. To bring the server back:
mcpx enable jira
MCPX sets "enabled": true and re-adds the server to every provider file.

Removing a server permanently

mcpx remove jira
If you provide the server name as an argument, MCPX moves straight to a confirmation prompt:
✔ Confirm removal of server "jira"? › No / Yes
If you omit the name, MCPX shows a list of all configured servers to choose from. After you confirm, the server is deleted from .agents/mcp.json and all provider files are regenerated without it.

Listing all servers

mcpx list
Prints a table of every server in .agents/mcp.json, showing its name, transport, command or URL, and enabled status.

Checking provider sync status

mcpx status
Compares each provider file on disk against what MCPX would generate from the current .agents/mcp.json and reports one of three states for each configured provider:
StatusMeaning
syncThe provider file matches MCPX’s expected output exactly
desyncThe file exists but its contents differ from expected (e.g. edited manually)
missingThe provider file does not exist on disk
If any provider shows desync or missing, run:
mcpx sync
This regenerates every provider config file from scratch based on the current .agents/mcp.json.

Manually editing .agents/mcp.json

Direct edits to .agents/mcp.json are fully supported. The file is plain JSON and you can add, change, or remove server entries, update the providers list, or toggle enabled flags with any text editor. The canonical field order MCPX expects is:
enabled → transport → url → headers → command → args → env
After any manual edit, run mcpx sync to push the changes out to all provider files:
mcpx sync
MCPX reports each file as created, updated, unchanged, or error so you can see exactly what changed.

Build docs developers (and LLMs) love