Mcp MCP Server

@extension.dev/mcp

Give your AI agent hands for browser extension development. 34 MCP tools that scaffold, run, inspect, debug, test, and build cross-browser extensions on your machine, plus a platform lane (private alpha) to share and publish them.

claude mcp add extension-dev npx @extension.dev/mcp

Works with Claude Code, Claude Desktop, Cursor, and any MCP client.

extension.dev · Docs · Templates · Discord

Why an MCP server for extensions

Extensions fail silently: content scripts that never inject, panels that never open, permissions that return undefined with no error. These tools give the agent eyes on the live browser, so it debugs from evidence instead of guessing.

• Scaffold from the 50+ templates behind templates.extension.dev, or add a popup, sidebar, or content script to an existing project
• Run the dev server with HMR in Chrome, Firefox, Edge and every browser below, plus Safari on macOS (no HMR yet)
• See the live DOM, logs from every extension context, chrome.storage, and the loaded-extension list
• Act: evaluate code in any context, trigger the action button and commands, reload the extension
• Test: state expectations about the running extension and get one verdict each
• Ship: validate the manifest cross-browser and build for production. On the platform lane: share a preview link, promote a build, and submit to the stores

Built on Extension.js, the open source framework extension.dev sponsors.

Watch it work

Browsers

extension_dev opens the extension in the browser you name.

The Chromium family and Firefox get HMR, control, eval, inspect and assert (Firefox over its debugger protocol and the agent bridge, no CDP). Safari gets dev and build on macOS, no HMR and no inspect; the full list of what works there is under Safari. Plus Vivaldi, Yandex, Waterfox, Zen and Floorp, and any Chromium or Gecko binary by path.

Clients

Setup

Claude Code

claude mcp add extension-dev -- npx @extension.dev/mcp --features=local,platform

Or install it as a plugin, the MCP server plus the /extension, /extension-add, /extension-debug, and /extension-publish commands in one step:

/plugin marketplace add extensiondev/mcp
/plugin install extension-mcp@extensiondev-mcp

Cursor

Or paste the .mcp.json block below into .cursor/mcp.json.

VS Code

code --add-mcp '{"name":"extension-dev","command":"npx","args":["@extension.dev/mcp","--features=local,platform"]}'

Or paste it into .vscode/mcp.json under servers, with "type": "stdio" on the entry.

Codex

codex mcp add extension-dev -- npx @extension.dev/mcp --features=local,platform

Or write it into ~/.codex/config.toml as a [mcp_servers.extension-dev] table with the same command and args.

Other clients (Claude Desktop and .mcp.json)

.mcp.json:

{
  "mcpServers": {
    "extension-dev": {
      "command": "npx",
      "args": [
        "@extension.dev/mcp",
        "--features=local,platform"
      ]
    }
  }
}

Flags

• By default the server exposes the 23 of its 34 tools that work on this machine (the 11 platform tools are off). --features=local,platform adds the platform group. Env: EXTENSION_DEV_FEATURES.
• --no-ship refuses every call that puts something in front of other people (publish, promote, a real submit, a shared preview, a revoke). Env: EXTENSION_DEV_NO_SHIP=1.
• --project <workspace>/<project> pins the server to one project. Env: EXTENSION_DEV_PROJECT.

A refused call answers E_TOOL_DISABLED with the flag to change. Human approval for store submissions and stable promotions, the MCP annotations every tool carries, and the <untrusted-data-ID> fence around page-written text are described under Server flags.

Telemetry

extension_create sends one draft_seeded event to PostHog at us.i.posthog.com after a successful scaffold (template slug, source and commit, a random per-process session id, never a path or a name), and the platform tools send a per-install id header with their calls. EXTENSION_DEV_NO_TELEMETRY=1 or DO_NOT_TRACK=1 stops both. The full payload is listed under Telemetry.

Pair with the skill

This server gives agents hands; @extension.dev/skill gives them judgment: the cross-browser rules, silent-failure gotchas, debugging playbooks, and store checklist, in the open Agent Skills format. The package also ships Claude Code rules and the four slash commands under claude/.

npm i -D @extension.dev/skill
mkdir -p .claude/skills && cp -R node_modules/@extension.dev/skill/skills/extension-dev .claude/skills/

Tools

On by default, the 23 that work on this machine:

On with --features=local,platform, the 11 that reach the extension.dev platform (private alpha):

A dev session carries the control channel that extension_storage, extension_reload, extension_open and extension_dom_snapshot ride: it is local, same machine, same user, and on unless extension_dev is called with allowControl: false. extension_eval is the one gate that stays off until allowEval: true is passed on extension_dev (it implies control). A session does not change its gates on a second call: call extension_dev again with what you need plus replace: true, which stops the first session.

Asserting instead of guessing

Every other tool hands back a reading. extension_assert states the expectation and returns the verdict.

{
  "projectPath": "/path/to/extension",
  "expect": [
    { "assert": "background-worker-booted" },
    { "assert": "surface-rendered", "surface": "popup", "selector": "[data-testid=root]" },
    { "assert": "storage-key-present", "key": "settings", "area": "local" },
    { "assert": "console-errors-empty", "context": ["background", "popup"] },
    { "assert": "content-script-injected", "url": "https://shop.example/cart" }
  ]
}

Each check comes back pass, fail or inconclusive, and the run passes only when every check passed. inconclusive means this platform cannot cover the question today, and the check carries settledBy naming the evidence that would answer it: a content script passes only on a line it wrote itself, "no console errors" over a session that never built is inconclusive, and a read the session refuses (chrome.storage on a session started with allowControl: false) is inconclusive rather than a failure.

Safari

A Safari dev session runs on the same bridge as every other engine: on Extension.js 4.1.21 or newer, extension_dev with browser: "safari" (macOS with Xcode) builds the app, opens it, reloads it on every save and streams its logs. Safari's MV3 background CSP blocks eval, there is no CDP or RDP path for extension_inspect, and opening a tab needs a safaridriver session; the limits are listed under Safari.

Platform (private alpha)

The eleven platform tools connect agents to extension.dev. They stay off until the server is started with --features=local,platform, and sharing, publishing, promoting and submitting need a login:

npx @extension.dev/mcp login --project <workspace>/<project>

You approve a code at extension.dev/device; no GitHub token reaches your machine, and the project-scoped token is stored locally, never returned to the agent, and lives at most 7 days. extension_preview_web with share: true uploads the build it just made and returns a link that renders those bytes in the web emulator, with its expiresAt and a revokeUrl. extension_publish returns the shareable URL of a build extension.dev already holds; extension_submit sends a built extension into store review through extension.dev, which holds your store credentials, and defaults to a dry run.

The details, the approval flow and the batch login for several projects are under Share a build in progress, Publish is not submit and Login.

Community

• Join the extension.dev Discord for help and feedback
• Browse production-ready templates at templates.extension.dev
• Follow the platform's public packages on GitHub
• Report Extension.js framework issues on GitHub

License

Apache-2.0 (c) 2026 Cezar Augusto and the extension.dev collaborators. See LICENSE.