# extensiondev/mcp [Health: Active] **Category:** 💻 Developer Tools **Repository:** https://github.com/extensiondev/mcp **GitHub Stars:** 1 **Views:** 0 **Installs:** 0 **Upvotes:** 0 **Directory Page:** https://allmcps.com/mcp/mcp-291 ## Description Build, run, inspect, and publish browser extensions from any MCP client. 28 tools, 11 browsers. ## Claude Desktop Quick Installation Install path detected from listing signals. Uses `npx` (confidence: high): ```json "mcpServers": { "mcp": { "command": "npx", "args": ["-y","@extension.dev/mcp"] } } ``` ## Documentation & README [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. Logo ```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
| Claude Code | Claude Desktop | Cursor | | :-: | :-: | :-: | | Claude Code | Claude Desktop | Cursor |
## 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) | | 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@` 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. ## Sharing a build in progress An unpacked extension is unusually hard to hand to someone: the only way to look at a colleague's work-in-progress has been to take their zip and run untrusted code with real browser permissions on your own machine. `extension_preview_web` with `share: true` uploads the `dist/` it just built and returns a link that renders those exact bytes in the emulator. Whoever opens it installs nothing and signs in to nothing, which is what lets a designer, a PM, or a reviewer into the loop at all. Those bytes run in an isolated sandbox origin or they do not run at all: preview refuses a shared build rather than serving it in its own renderer. Sharing needs auth (`extension_auth` or `EXTENSION_DEV_TOKEN`), the link lives 30 days, and `DELETE`ing the returned `revokeUrl` with the same token kills it early. Re-sharing an unchanged build returns that same link rather than a second one, and only a revoked link is replaced by a different one, because revocation is permanent: the address is burned and never resolves again. That makes `revokeUrl` the handle to the link you just made, so every share is also appended to `.extension.dev/shared-previews.json` in the project (gitignored) so it survives losing the tool output. The upload holds up to 2,000 files and about 64MB of text, or roughly 48MB when the build is mostly images, fonts or wasm, which travel base64-encoded. Without `share`, the tool returns a local-only deep link and uploads nothing. `extension_shares` is the other half of that: it lists every link the token has shared, live and dead, with the `previewUrl` and `revokeUrl` of each, and revokes one by `artifactId` or by pasting any of its URLs. Pass `projectPath` and it reconciles the platform's answer with the project's own record, so a link shared from another machine shows up as `remoteOnly` and a record with nothing behind it any more shows up under `localOnly`. It never rewrites the local file. That is a different job from shipping. Use `share` for the build you are holding right now; use `extension_publish` and `extension_release_promote` below for builds your CI has released. ## From preview to store The platform tools connect agents to [extension.dev](https://extension.dev): `extension_auth` runs extension.dev's own device flow (you approve the code at [extension.dev/device](https://extension.dev/device), and GitHub is federated server-side, so no GitHub token ever reaches your machine) and stores a project-scoped token locally (never returned to the agent), `extension_publish` turns a build your project has already published into a shareable URL, and `extension_release_promote` promotes a tested build to a release channel from CI or an agent session, no browser required. `extension_submit` submits a built extension to the Chrome Web Store, Edge Add-ons, and Firefox AMO through extension.dev, which holds your store credentials and dispatches the release from your project's mirror CI, it defaults to a dry run and store credentials are never tool arguments. Safari and the App Store are one paid lane on the platform, so a free workspace is refused there and the other three stores are unaffected. The two verbs are not interchangeable: `extension_publish` pushes to the extension.dev platform, `extension_submit` sends the build into a store's review queue, which is irreversible. After a real submission, `extension_release_status` reads the recorded outcome, per-store credential health, and review state from the project's public registry, so agents and CI can answer "was it approved?" without a console visit. Access tokens live at most 7 days; CI pipelines re-mint them from the console's Access tokens page. ## The extension.dev stack | Package | Use it to | | --- | --- | | [`@extension.dev/skill`](https://www.npmjs.com/package/@extension.dev/skill) | Teach AI agents the judgment half: cross-browser rules, gotchas, playbooks | | [`@extension.dev/artifact-integrity`](https://www.npmjs.com/package/@extension.dev/artifact-integrity) | Check an artifact against a declared SHA-256 and gate CI on the result| All of it rides on [Extension.js](https://github.com/extension-js/extension.js), the open-source cross-browser extension framework. ## Community - Join the extension.dev [Discord](https://discord.gg/v9h2RgeTSN) for help and feedback - Browse production-ready templates at [templates.extension.dev](https://templates.extension.dev) - Follow the platform's public packages on [GitHub](https://github.com/extensiondev) - Report Extension.js framework issues on [GitHub](https://github.com/extension-js/extension.js/issues) ## License Apache-2.0 (c) 2026 Cezar Augusto and the extension.dev collaborators. See [LICENSE](https://github.com/extensiondev/mcp/blob/HEAD/LICENSE).