Skip to content

HTTP MCP Servers

AllAgents acts as the MCP client for HTTP servers it manages. One command connects to the server, handles OAuth when required, saves the selected project, user, or profile declaration, and syncs every selected AI client:

Terminal window
allagents mcp add tradingview https://mcp.tradingview.com/mcp

You do not need to run a separate proxy or authentication command.

Use a stable name and the server’s HTTP endpoint:

Terminal window
allagents mcp add deepwiki https://mcp.deepwiki.com/mcp
allagents mcp add tradingview https://mcp.tradingview.com/mcp

For an HTTP server, mcp add:

  1. Connects as the AllAgents MCP client
  2. Opens a browser if the server requires OAuth
  3. Verifies the MCP connection before changing the selected declaration
  4. Stores the server under that destination’s mcpServers
  5. Routes the selected AI clients through AllAgents and syncs their configs

Public servers such as DeepWiki complete without a browser. OAuth servers such as TradingView prompt for login on the first connection.

The same command supports both environments:

  • Local browser: approve access and let the browser return to the loopback callback. The terminal continues automatically.
  • Remote or headless host: open the printed authorization URL on another device. After approval, copy the complete loopback callback URL from the browser address bar and paste it into the waiting terminal prompt.

AllAgents accepts only the registered loopback address with the exact OAuth state.

In a non-interactive shell, AllAgents still verifies the connection without opening a browser. Public servers and servers with valid cached credentials succeed. If fresh OAuth consent is required, the command fails before changing the workspace; rerun it in an interactive terminal.

Terminal window
allagents mcp add internal https://mcp.internal.corp \
--header Authorization=Bearer-token \
--client claude \
--client codex,copilot

--client is repeatable and comma-compatible. It limits both server sync and AllAgents routing; duplicate values are ignored in first-seen order. Without --client, routing stays dynamic so clients added to the destination later receive the same AllAgents-managed connection. --header values are sent only to the MCP server origin, not to OAuth discovery or identity-provider origins.

Profile declarations accept only exact environment references for header values:

Terminal window
allagents mcp add tradingview https://mcp.tradingview.com/mcp \
--profile markets \
--header 'Authorization=${TRADINGVIEW_TOKEN}'

Generated profile bridge arguments store the header-to-variable binding, not the resolved secret. AllAgents resolves the variable immediately before the MCP connection and fails clearly when it is missing.

Use the configured server name, not its URL:

Terminal window
allagents mcp reauth tradingview
allagents mcp reauth tradingview --scope user
allagents mcp reauth tradingview --profile markets

reauth clears only the selected destination’s cached OAuth registration and tokens, then runs a fresh connection and login. It does not revoke the grant at the remote provider. Reconnect the AI client afterward if it already had an MCP session open.

Stdio servers use the same add command and run directly rather than through the HTTP client:

Terminal window
allagents mcp add gh-server npx \
--arg=-y \
--arg=@modelcontextprotocol/server-github \
-e GH_TOKEN=ghp_xxx

AI clients have different MCP transport support. AllAgents normalizes that difference: HTTP servers added with mcp add are synced as stdio commands that launch AllAgents’ internal HTTP bridge. OAuth registration and tokens are therefore shared instead of being configured independently in every client.

The generated client config may contain an internal invocation like:

{
"tradingview": {
"command": "npx",
"args": [
"-y",
"allagents@<version>",
"mcp",
"proxy",
"https://mcp.tradingview.com/mcp"
]
}
}

For a named profile, the generated arguments also include --profile <name>. That hidden selector makes every client inside one profile share the same profile-owned credentials without sharing them with another profile.

This is generated plumbing, not a setup command. AllAgents pins the package version that created the config, and npx reuses npm’s package cache on later launches.

Servers declared by plugins are not added through mcp add. To route those through AllAgents, use the advanced destination-local mcpProxy setting:

mcpProxy:
clients:
- codex
servers:
plugin-server:
proxy:
- claude
- copilot

The optional clients list applies to every HTTP server in that destination. Per-server lists add clients for only the named server, and * selects every eligible client. Profiles place the same shape beside their own mcpServers under profiles.<name>.mcpProxy; profile policy never uses qualified global client IDs. Stdio servers are never transformed.

AllAgents caches OAuth client registration, tokens, PKCE verifier, and discovery metadata per server URL. Project and ordinary user declarations share the ordinary cache:

~/.allagents/oauth-proxy/<hash-of-server-url>/

Each named profile owns an isolated cache:

~/.allagents/profiles/<profile>/oauth-proxy/<hash-of-server-url>/

Both contain client-info.json, tokens.json, code-verifier.txt, and discovery.json. Clients inside one profile share those files; different profiles do not. Later connections reuse valid tokens and refresh expired access tokens when possible. mcp reauth --profile <name> resets only that profile. Removing an installed or declared-only profile removes its OAuth subtree with its other profile-owned runtime state. Cleanup rejects symbolic-link or non-directory OAuth roots and retains retryable state on failure.

The generated bridge requires Node.js with npx available. A global AllAgents installation is not required: both setup and the generated MCP connection can use the npm cache.

The first bridge launch downloads the pinned AllAgents package if that version is not already cached. Later launches reuse the cached package. Environments that must work offline should prime the cache before disconnecting.

HTTP MCP routing supports project, ordinary user, and named profile destinations. Omit destination flags for project scope, use --scope user for ordinary user configuration, or --profile <name> for a profile. --scope and --profile cannot be combined. From the home directory, the project path aliases the user workspace, so an unflagged command resolves to user scope and explicit --scope project is rejected.

Destination Codex Copilot
Project .codex/config.toml .github/mcp.json
User ~/.codex/config.toml ~/.copilot/mcp-config.json
Profile ~/.allagents/profiles/<name>/clients/codex/home/<name>.config.toml ~/.allagents/profiles/<name>/clients/copilot/home/mcp-config.json

Project and ordinary user updates are MCP-only. Updating an installed profile uses the ownership-aware profile reconciler because some clients combine MCP and settings in one file. Editing a declared but uninstalled profile does not implicitly install it.