@extension.dev/mcp

Give your AI agent hands for browser extension development. 30 MCP tools that scaffold, run, inspect, debug, and publish cross-browser extensions.

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

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

extension.dev · Extension.js · Templates · Examples · 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. An agent editing files blind will happily "fix" all of them without noticing none of them work.

These tools give agents eyes on the live browser, so they debug from evidence instead of guessing:

• Scaffold from the 50+ template catalog behind templates.extension.dev, or add a popup, sidebar, or content script to an existing project
• Run the dev server with HMR in Chrome, Edge, Firefox, Brave, Opera, Vivaldi, Yandex, Waterfox, LibreWolf, or any Chromium- or Gecko-based binary, plus Safari on macOS (no HMR yet), no build config
• See the live DOM, unified logs from every extension context, chrome.storage contents, and the loaded-extension list
• Act: evaluate code in any context, trigger the action button and commands, reload the extension, replay events
• Ship: validate the manifest cross-browser, build for production, publish a shareable preview, and promote builds to release channels headlessly

Built on Extension.js, the open-source cross-browser extension framework.

Clients

Claude Code	Claude Desktop	Cursor

Setup

Claude Code

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

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

Claude Desktop / .mcp.json

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

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, packaged in the open Agent Skills format. With both installed, agents know to verify against the live browser instead of guessing, and these tools make that a one-call operation.

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

Claude Code project integration

The package ships drop-in instructions, slash commands, and rules for extension projects:

# Rules (how Claude understands your project)
cp node_modules/@extension.dev/mcp/claude/CLAUDE.md ~/my-extension/.claude/CLAUDE.md

# Slash commands (/extension, /extension-add, /extension-debug, /extension-publish)
mkdir -p ~/my-extension/.claude/commands
cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/commands/

Tools

Browser-launching tools (dev, start) shell out to the extension CLI, the project's own node_modules/.bin/extension when present, otherwise npx extension@<pinned> at the version this package is verified against; everything else runs in-process.

Asserting instead of guessing

Every other tool here hands back a reading: a DOM, a log window, an evaluated expression. Turning a reading into "the popup works" was left to the agent, as a string of JavaScript it wrote on the spot, which is the guesswork the paired skill exists to prevent. 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 as pass, fail or inconclusive, and the run is a pass only when every check passed. inconclusive is the part that matters: it means this platform cannot cover the question today, and the check carries a settledBy naming the evidence that would answer it. A content script's execution is not observable from outside its isolated world, so content-script-injected passes only on a line the script itself wrote and is inconclusive over a declared match, never a pass. "No console errors" over a session that never built is inconclusive too, because zero errors and zero events are the same number. A read the platform refuses, such as chrome.storage on a session started without allowControl, is inconclusive rather than a failure: nothing was learned about the extension.

The verdict document is the same grammar the preview lane's CI verdict uses (@extension.dev/preview-verdict), with its own contract name and its own check registry, so a document from one lane can never be mistaken for the other's. Each check here names the preview check it is the live-browser counterpart of, and a contract test holds the two grammars together.

Sharing a build in progress