MCP Server Plugins
MCP Server Plugins
Plugins can expose MCP servers to Claude Code by including a .mcp.json file in the plugin root. Athena merges all loaded plugins' MCP configs and passes the result to the spawned Claude process via --mcp-config.
How MCP Integration Works
- Each plugin directory that contains a
.mcp.jsonfile contributes itsmcpServersentries to a merged config. - Athena writes the merged config to a temp file at startup:
/tmp/athena-mcp-<PID>.json. - This file is passed to Claude Code via the
--mcp-configflag. - Claude Code manages the MCP server processes; Athena does not start or monitor them directly.
MCP server names must be unique across all loaded plugins. A collision causes a startup error:
MCP server name collision: "my-server" is defined by multiple plugins.
Each MCP server must have a unique name across all plugins.
Plugin .mcp.json Format
{
"mcpServers": {
"my-server": {
"command": "node",
"args": ["./server/index.js"],
"env": {
"MY_VAR": "value"
}
}
}
}The format follows Claude Code's standard MCP config format. The command and args fields specify how to start the server process.
Skills with MCP Access
When a skill in a plugin that has a .mcp.json is invoked, it runs with the plugin's MCP server's tools available to Claude. This is how the e2e-test-builder plugin's browser automation skills get access to the agent-web-interface tools.
agent-web-interface
agent-web-interface is a browser automation MCP server built specifically for LLM agents. It produces semantic page snapshots instead of raw DOM dumps, optimized for token efficiency and reliable agent-driven navigation.
The Problem It Solves
Most browser automation tools expose entire DOMs or accessibility trees to the model, leading to rapid token exhaustion. agent-web-interface presents pages in a form aligned with how language models reason about interfaces — compact, structured, focused on user-visible intent.
Benchmarks
Benchmarks against Playwright MCP show approximately 19% fewer tokens consumed and approximately 33% faster task completion on common navigation tasks. Results are task-dependent.
How It Works
- The browser is controlled via Puppeteer and Chrome DevTools Protocol (CDP)
- Pages are reduced into semantic regions and actionable elements
- A structured snapshot is generated and sent to the agent
- Actions are resolved against stable semantic identifiers rather than fragile CSS selectors
CLI Arguments
| Argument | Description | Default |
|---|---|---|
--headless | Run browser in headless mode (true/false) | false |
--browserUrl | HTTP endpoint to connect to an existing browser | — |
--wsEndpoint | WebSocket endpoint to connect to an existing browser | — |
--autoConnect | Auto-connect to Chrome 144+ via DevToolsActivePort | false |
--isolated | Use isolated temp profile instead of persistent profile | false |
--userDataDir | Chrome user data directory | Platform default |
--channel | Chrome channel (chrome, chrome-canary, chrome-beta, chrome-dev) | chrome |
--executablePath | Path to Chrome executable | — |
The browser launches automatically on the first tool call — no explicit initialization step needed.
Environment Variables
| Variable | Description | Default |
|---|---|---|
AWI_TRIM_REGIONS | Set to false to disable region trimming | true |
CEF_BRIDGE_HOST | CDP host for browser connection | 127.0.0.1 |
CEF_BRIDGE_PORT | CDP port for browser connection | 9223 |
Connecting to Your Chrome Profile (Chrome 144+)
To connect with your existing bookmarks, extensions, and logged-in sessions:
- Navigate to
chrome://inspect/#remote-debuggingin Chrome - Enable remote debugging and allow the connection
- Start the server with
--autoConnect
{
"mcpServers": {
"agent-web-interface": {
"command": "npx",
"args": ["agent-web-interface@latest", "--autoConnect"]
}
}
}