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

  1. Each plugin directory that contains a .mcp.json file contributes its mcpServers entries to a merged config.
  2. Athena writes the merged config to a temp file at startup: /tmp/athena-mcp-<PID>.json.
  3. This file is passed to Claude Code via the --mcp-config flag.
  4. 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

  1. The browser is controlled via Puppeteer and Chrome DevTools Protocol (CDP)
  2. Pages are reduced into semantic regions and actionable elements
  3. A structured snapshot is generated and sent to the agent
  4. Actions are resolved against stable semantic identifiers rather than fragile CSS selectors

CLI Arguments

ArgumentDescriptionDefault
--headlessRun browser in headless mode (true/false)false
--browserUrlHTTP endpoint to connect to an existing browser
--wsEndpointWebSocket endpoint to connect to an existing browser
--autoConnectAuto-connect to Chrome 144+ via DevToolsActivePortfalse
--isolatedUse isolated temp profile instead of persistent profilefalse
--userDataDirChrome user data directoryPlatform default
--channelChrome channel (chrome, chrome-canary, chrome-beta, chrome-dev)chrome
--executablePathPath to Chrome executable

The browser launches automatically on the first tool call — no explicit initialization step needed.

Environment Variables

VariableDescriptionDefault
AWI_TRIM_REGIONSSet to false to disable region trimmingtrue
CEF_BRIDGE_HOSTCDP host for browser connection127.0.0.1
CEF_BRIDGE_PORTCDP port for browser connection9223

Connecting to Your Chrome Profile (Chrome 144+)

To connect with your existing bookmarks, extensions, and logged-in sessions:

  1. Navigate to chrome://inspect/#remote-debugging in Chrome
  2. Enable remote debugging and allow the connection
  3. Start the server with --autoConnect
{
  "mcpServers": {
    "agent-web-interface": {
      "command": "npx",
      "args": ["agent-web-interface@latest", "--autoConnect"]
    }
  }
}