mcp

[npm-version-image]: https://img.shields.io/npm/v/%40extension.dev%2Fmcp.svg?color=26FFB8
[npm-version-url]: https://www.npmjs.com/package/@extension.dev/mcp
[npm-downloads-image]: https://img.shields.io/npm/dm/%40extension.dev%2Fmcp.svg?color=26FFB8
[npm-downloads-url]: https://www.npmjs.com/package/@extension.dev/mcp
[discord-image]: https://img.shields.io/discord/1253608412890271755?label=Discord&logo=discord&style=flat&color=26FFB8
[discord-url]: https://discord.gg/v9h2RgeTSN

# @extension.dev/mcp [![Version][npm-version-image]][npm-version-url] [![Downloads][npm-downloads-image]][npm-downloads-url] [![Discord][discord-image]][discord-url]

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

<img alt="Logo" align="right" src="https://media.extension.land/brand/extension-dev/logo-dock.png" width="15.5%" />

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

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

[extension.dev](https://extension.dev) · [Extension.js](https://extension.js.org) · [Templates](https://templates.extension.dev) · [Examples](https://github.com/extension-js/examples) · [Discord](https://discord.gg/v9h2RgeTSN)

## 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](https://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](https://extension.js.org), the open-source cross-browser extension framework.

## Clients

<div align="center">

| <img alt="Claude Code" src="https://media.extension.land/logos/devtools/claude-code.svg" width="70"> | <img alt="Claude Desktop" src="https://media.extension.land/logos/ai/claude.svg" width="70"> | <picture><source media="(prefers-color-scheme: dark)" srcset="https://media.extension.land/logos/devtools/cursor-dark.svg"><img alt="Cursor" src="https://media.extension.land/logos/devtools/cursor.svg" width="70"></picture> |
| :-: | :-: | :-: |
| Claude Code | Claude Desktop | Cursor |

</div>

## Setup

### Claude Code

```bash
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

[![Install MCP Server](https://cursor.com/deeplink/mcp-install-dark.svg)](https://cursor.com/en/install-mcp?name=extension-dev&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyJAZXh0ZW5zaW9uLmRldi9tY3AiXX0%3D)

### Claude Desktop / `.mcp.json`

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

### Pair with the skill

This server gives agents hands; [`@extension.dev/skill`](https://www.npmjs.com/package/@extension.dev/skill) gives them judgment: the cross-browser rules, silent-failure gotchas, debugging playbooks, and store checklist, packaged in the open [Agent Skills](https://agentskills.io) format. With both installed, agents know to verify against the live browser instead of guessing, and these tools make that a one-call operation.

```bash
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:

```bash
# 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

| Tier | Tool | Description |
| ---- | ---- | ----------- |
| build | `extension_create` | Scaffold from a template |
| build | `extension_templates` | Browse 50+ templates (`list`) and read one's source (`source`) |
| build | `extension_add_feature` | Add sidebar/popup/content script |
| build | `extension_build` | Build for production |
| run | `extension_dev` | Dev server with HMR |
| run | `extension_start` | Build + launch the production build (`build: false` launches the existing dist; `outputPath` launches any prebuilt unpacked directory) |
| run | `extension_wait` | Poll the dev-server ready contract |
| run | `extension_stop` | Stop a dev/start/preview session (server + browser) |
| see | `extension_manifest_validate` | Cross-browser manifest validation |
| see | `extension_analyze` | Static analysis of the built extension on disk |
| see | `extension_inspect` | Deep live inspection of a running extension (closed shadow roots, probes) |
| see | `extension_dom_snapshot` | Shallow DOM snapshot of a chosen tab or extension surface over the agent bridge |
| see | `extension_list_extensions` | List loaded extensions (Chromium and Firefox) |
| see | `extension_logs` | Stream logs from every context |
| see | `extension_doctor` | Diagnose the dev session leg by leg (ready contract, ports, token, executor, browser) |
| see | `extension_theme_verify` | Verify a Chrome theme manifest against the colors Chrome actually paints |
| test | `extension_assert` | State expectations about a running extension and get one verdict each: pass, fail, or inconclusive |
| act | `extension_eval` | Evaluate in a context (needs `allowEval: true` on `extension_dev`) |
| act | `extension_storage` | Read/write `chrome.storage` |
| act | `extension_reload` | Reload extension or tab |
| act | `extension_open` | Open a surface / trigger `action`, `command` |
| browsers | `extension_browsers` | Detect, list, install, and uninstall browsers |
| platform | `extension_auth` | Device login at extension.dev, plus login status and logout |
| platform | `extension_project_create` | Create the extension.dev project for a built extension, headless, via device approval |
| platform | `extension_preview_web` | Render a build in the web emulator, and share it as a link |
| platform | `extension_shares` | List every link you have shared, and revoke one permanently |
| platform | `extension_publish` | Publish a shareable preview to extension.dev |
| platform | `extension_release_promote` | Promote a build to a release channel, headless |
| platform | `extension_submit` | Submit for store review: Chrome, Firefox and Edge, through extension.dev |
| platform | `extension_release_status` | Read release channels, recent builds, and store submission and review state |

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.

```jsonc
{
  "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.

## Safari

A Safari dev session runs on the same bridge as every other engine. On
Extension.js 4.1.28 or newer,