@extension.dev/mcp 7.0.0 → 10.0.0

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "extension-mcp",
       "source": "./",
       "description": "MCP tools for browser extension development: scaffold from 60+ templates, run the dev server with HMR, inspect the live DOM and logs, and publish store-ready builds for Chrome, Edge, and Firefox.",
-      "version": "7.0.0",
+      "version": "10.0.0",
       "category": "development",
       "author": {
         "name": "Cezar Augusto"

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "extension-mcp",
   "description": "MCP tools for browser extension development: scaffold from 60+ templates, run the dev server with HMR, inspect the live DOM and logs, and publish store-ready builds for Chrome, Edge, and Firefox. Ships /extension, /extension-add, /extension-debug, and /extension-publish commands.",
-  "version": "7.0.0",
+  "version": "10.0.0",
   "author": {
     "name": "Cezar Augusto",
     "email": "hello@extension.dev",

package/CHANGELOG.md

@@ -1,5 +1,276 @@
 # Changelog
 
+## 10.0.0
+
+Every tool now returns the same frame. Before this, 28 tools hand-built 142
+different JSON shapes: `ok` appeared on 71 of them, `error` on 67, `hint` on 60,
+`message` on 49, `status` on 46, and five more keys carried the same meaning
+under different names. An agent could not tell success from failure without
+knowing which tool it had called.
+
+The frame is schema 1, the same one the Extension.js CLI emits under
+`--output json`:
+
+```json
+{
+  "schema": 1,
+  "ok": false,
+  "command": "extension_dev",
+  "status": "compile-failed",
+  "value": null,
+  "error": { "code": "E_FIRST_COMPILE", "message": "…" },
+  "hint": "…",
+  "warnings": []
+}
+```
+
+`command` names the tool. `status` is a kebab-case word from that tool's own
+vocabulary. `error.code` is stable and worth branching on; `error.message` is
+free copy and is not. The payload moved under `value`, and every advisory note
+that used to have its own key is now an entry in `warnings`.
+
+**Breaking.** Every payload key moved one level down. `build.success` is now
+`ok`, `doctor.healthy` is now `ok`, `manifest_validate.valid` is now
+`value.valid`, and `wait` gained the `ok` it never had. The ready contract's own
+`command` is carried as `value.sessionCommand`, because the envelope claims that
+key. `authorization_pending` became `authorization-pending`, with the old
+spelling echoed as `value.legacyStatus` for one minor.
+
+`extension_dev` and `extension_start` also stopped reading the dev server's
+prose to decide whether the first compile failed. They poll its `ready.json`
+contract instead, which splits a locked profile out of a dead browser and
+returns the compile errors as a list. The output scrape survives only as a
+fallback for a project whose own CLI predates the contract, is confined to one
+`@deprecated` module, and says so in `warnings` whenever it is used. The choice
+is a capability probe, never a version check: a project-local `extension` binary
+wins over this package's pin, so the version is not knowable in advance. The
+contract's own error stamps are read whatever the engine's age, so a locked
+profile is named as one the moment the engine records it.
+
+## 9.0.0
+
+Every client pays for this server's tool list at the start of every session,
+whether or not the user ever touches an extension. That list was 36 tools and
+52,403 bytes on the wire (roughly 13,100 tokens). It is now 28 tools and
+43,214 bytes (roughly 10,800 tokens), a 17.5% cut, with no capability removed.
+Eleven tools folded into the four that already owned their resource,
+`extension_preview` folded into `extension_start`, and the prose was tightened
+everywhere it repeated the schema or a parameter name.
+
+9.0.0 lands close behind 8.0.0 on purpose. 8.0.0 renamed four tools for
+disambiguation; this release cuts what the surface costs. Both are breaking,
+adoption is still low, and doing them as one migration is cheaper for early
+users than spacing them out.
+
+### Migration
+
+| Old tool | New call |
+| --- | --- |
+| `extension_detect_browsers({ browsers })` | `extension_browsers({ action: "detect", browsers })` |
+| `extension_list_browsers()` | `extension_browsers({ action: "list" })` |
+| `extension_install_browser({ browser })` | `extension_browsers({ action: "install", browser })` |
+| `extension_uninstall_browser({ browser, all })` | `extension_browsers({ action: "uninstall", browser, all })` |
+| `extension_login({ project, deviceCode, api })` | `extension_auth({ action: "login", project, deviceCode, api })` |
+| `extension_whoami()` | `extension_auth({ action: "status" })` |
+| `extension_logout()` | `extension_auth({ action: "logout" })` |
+| `extension_list_templates({ surface, framework, tags, featured, query })` | `extension_templates({ action: "list", surface, framework, tags, featured, query })` |
+| `extension_get_template_source({ slug, files })` | `extension_templates({ action: "source", slug, files })` |
+| `extension_release_list({ workspace, project, api })` | `extension_release_status({ include: ["releases"], workspace, project, api })` |
+| `extension_store_status({ workspace, project, api })` | `extension_release_status({ include: ["stores"], workspace, project, api })` |
+| `extension_preview({ projectPath, browser, port, noBrowser, ...launch })` | `extension_start({ projectPath, build: false, browser, port, noBrowser, ...launch })` |
+
+Every argument keeps its name and its meaning. `action` defaults to the most
+common case (`detect`, `status`, `list`), so `extension_browsers({})` scans,
+`extension_auth({})` reports the login, and `extension_templates({})` lists.
+`extension_release_status` returns both sections by default and nests each
+under `releases` and `stores`; the old flat bodies are unchanged inside them.
+The CLI is untouched: `extension-mcp login|logout|whoami|release` still work
+exactly as before.
+
+`extension_submit`, `extension_publish`, `extension_analyze`,
+`extension_inspect` and `extension_dom_snapshot` were deliberately NOT merged.
+8.0.0 separated them because agents confused them; folding them behind an
+`action` parameter would hide that ambiguity rather than remove it.
+
+### Upgrading from 7.0.0
+
+Most installs are still on 7.0.0 and two majors have landed on top of it. Do
+both in one pass: apply the 8.0.0 renames, then the 9.0.0 merges above. 7.0.0
+advertised 36 tools; 9.0.0 advertises 28, and every capability survived.
+
+| 7.0.0 call | 9.0.0 call | Landed in |
+| --- | --- | --- |
+| `extension_deploy(...)` | `extension_submit(...)` | 8.0.0 |
+| `extension_inspect({ projectPath })` | `extension_analyze({ projectPath })` | 8.0.0 |
+| `extension_source_inspect(...)` | `extension_inspect(...)` | 8.0.0 |
+| `extension_dom_inspect(...)` | `extension_dom_snapshot(...)` | 8.0.0 |
+| `extension_detect_browsers({ browsers })` | `extension_browsers({ action: "detect", browsers })` | 9.0.0 |
+| `extension_list_browsers()` | `extension_browsers({ action: "list" })` | 9.0.0 |
+| `extension_install_browser({ browser })` | `extension_browsers({ action: "install", browser })` | 9.0.0 |
+| `extension_uninstall_browser({ browser, all })` | `extension_browsers({ action: "uninstall", browser, all })` | 9.0.0 |
+| `extension_login({ project, deviceCode, api })` | `extension_auth({ action: "login", project, deviceCode, api })` | 9.0.0 |
+| `extension_whoami()` | `extension_auth({ action: "status" })` | 9.0.0 |
+| `extension_logout()` | `extension_auth({ action: "logout" })` | 9.0.0 |
+| `extension_list_templates({ surface, framework, tags, featured, query })` | `extension_templates({ action: "list", surface, framework, tags, featured, query })` | 9.0.0 |
+| `extension_get_template_source({ slug, files })` | `extension_templates({ action: "source", slug, files })` | 9.0.0 |
+| `extension_release_list({ workspace, project, api })` | `extension_release_status({ include: ["releases"], workspace, project, api })` | 9.0.0 |
+| `extension_store_status({ workspace, project, api })` | `extension_release_status({ include: ["stores"], workspace, project, api })` | 9.0.0 |
+| `extension_preview({ projectPath, browser, port, noBrowser, ...launch })` | `extension_start({ projectPath, build: false, browser, port, noBrowser, ...launch })` | 9.0.0 |
+
+Read the `extension_inspect` row before any of the others. That name exists in
+both versions and does not mean the same thing in each. In 7.0.0 it read a
+BUILT extension's files off disk. In 9.0.0 it reads a RUNNING extension over
+the browser's debugger protocol and needs a live `extension_dev` or
+`extension_start` session. A 7.0.0 call left alone does not fail with an
+unknown-tool error, it silently reaches the wrong tool and reports no dev
+session instead of the file sizes you asked for. The disk reader is
+`extension_analyze` now. Every call that passed a bare `projectPath` and
+expected sizes, permissions and store-readiness back has to move.
+
+`extension_deploy` carried its error names with it into `extension_submit`:
+`DeployAuthError`, `DeployInputError`, `DeployConfigError`,
+`DeployNetworkError` and `DeployError` are now `SubmitAuthError`,
+`SubmitInputError`, `SubmitConfigError`, `SubmitNetworkError` and
+`SubmitError`. Anything branching on those strings has to move with them.
+
+Every argument keeps its name and its meaning across both majors, with two
+exceptions:
+
+- `extension_release_status` nests what the two 7.0.0 tools returned flat,
+  under `releases` and `stores`. The bodies inside are byte-for-byte the old
+  ones. Omitting `include` returns both sections.
+- `extension_start` gained `build`, defaulting to `true`. `build: false` is
+  what `extension_preview` was.
+
+Nothing else moved. `extension_publish`, `extension_preview_web`,
+`extension_shares`, `extension_release_promote`, `extension_dev`,
+`extension_build`, `extension_create`, `extension_add_feature`,
+`extension_wait`, `extension_stop`, `extension_logs`, `extension_eval`,
+`extension_storage`, `extension_reload`, `extension_open`,
+`extension_list_extensions`, `extension_manifest_validate`,
+`extension_theme_verify` and `extension_doctor` are unchanged in name and in
+arguments, and the CLI (`extension-mcp login|logout|whoami|release`) never
+moved at all.
+
+### Merged
+
+- **Four browser tools are one.** `extension_browsers` detects, lists,
+  installs, and uninstalls. `detect` and `list` were the confusable pair: both
+  answered "what browsers do I have", and telling them apart took a sentence of
+  prose in each description. An action enum settles it in the schema.
+- **Three auth tools are one.** `extension_auth` signs in, reports the stored
+  login, and clears it. They were a lifecycle triad that each re-explained the
+  same token model.
+- **Two template tools are one.** `extension_templates` searches the catalog
+  and reads a template's source. The slug you read comes from the list you just
+  searched, so the pair is one resource.
+- **The two read-only release tools are one.** `extension_release_status`
+  returns release channels and recent builds, browser-store submissions and
+  review state, or both. They took identical arguments and read the same
+  registry. `extension_release_promote` stays separate on purpose: it is the
+  only verb that writes, and putting a write behind the same `action`
+  parameter as a read is how an agent promotes a build it meant to list.
+- **`extension_preview` folded into `extension_start`.** Both answered "run the
+  production build in a browser"; the only difference was whether a build ran
+  first. That is now `build`, defaulting to `true`, which matches
+  `extension_preview_web`, where `build: false` already means the same thing.
+
+### Sharpened
+
+- **`extension_dev` and `extension_start` now say which one to pick.**
+  They are not merged: `dev` is the only tool that can unlock the control
+  channel (`allowControl`, `allowEval`) that `extension_storage`,
+  `extension_reload`, `extension_open`, `extension_dom_snapshot` and
+  `extension_eval` need, and `start` runs a production build with none of it.
+  A `mode` parameter would have made those flags look valid on a session that
+  cannot honor them. Instead each description now opens with the thing that
+  decides between them and names the other tool.
+- **Descriptions no longer repeat the schema.** The biggest cuts, in bytes of
+  description: `extension_shares` 1,661 to 1,250, `extension_preview_web`
+  1,151 to 639, `extension_submit` 1,478 to 1,194, `extension_eval` 1,128 to
+  831, `extension_wait` 985 to 784, `extension_list_extensions` 944 to 696,
+  `extension_dom_snapshot` 965 to 854. What was cut was prose that restated a
+  parameter name, repeated a property's own description, or explained the
+  response shape the response already carries. What was kept is anything that
+  stops a tool being misused: the `activeTab` gesture warning on
+  `extension_open`, the MV3 service-worker CSP note on `extension_eval`, the
+  profile-lock explanation on `extension_dev`, and the irreversibility of
+  `extension_submit` and of revoking a share.
+- **Repeated property schemas are shared.** `projectPath`, the session
+  `browser`, the call `timeout`, the platform `api` base and the launch browser
+  enum are defined once in `src/lib/common-schema.ts` instead of being
+  re-typed per tool.
+
+### Considered and rejected
+
+- **A smaller default surface with the rest opt-in.** The platform cluster
+  (`extension_auth`, `extension_publish`, `extension_submit`,
+  `extension_release_status`, `extension_release_promote`, `extension_shares`,
+  `extension_preview_web`) is 13 KB, about 30% of what is left, and is dead
+  weight for anyone building an extension locally without an extension.dev
+  account. Hiding it behind an env flag would cut the default surface by
+  roughly a third. It was not shipped because a hidden tool is an invisible
+  capability: an agent asked to publish would report that it cannot, which is
+  worse than the tokens. The version worth building expands the surface once a
+  login exists and announces it with `notifications/tools/list_changed`, and
+  that needs a client-by-client compatibility check first.
+
+### Added
+
+- `pnpm exec node scripts/tool-surface-size.mjs` starts the server, calls
+  `tools/list`, and reports exactly what a client receives: bytes per tool
+  split into description and schema, and the total. `--json` for the raw rows.
+  Before this, the cost of the tool surface was never measured, only guessed.
+
+## 8.0.0
+
+Four tools are renamed. Every rename fixes a name that made agents pick the
+wrong tool, and one of them could cost you a store submission you did not ask
+for. No behavior changes, no argument changes.
+
+### Migration
+
+| Old name | New name |
+| --- | --- |
+| `extension_deploy` | `extension_submit` |
+| `extension_inspect` | `extension_analyze` |
+| `extension_source_inspect` | `extension_inspect` |
+| `extension_dom_inspect` | `extension_dom_snapshot` |
+
+`extension_publish` is unchanged.
+
+### Renamed
+
+- **`extension_deploy` is now `extension_submit`.** The pair was inverted
+  against every other developer tool: `extension_publish` pushes a build to the
+  extension.dev platform, while `extension_deploy` submitted to the Chrome Web
+  Store, Firefox AMO, Edge Add-ons and the App Store. An agent told to "deploy
+  my extension" reached for the store tool, and picking wrong there means an
+  unintended store submission, which is irreversible. "Submit" is the stores'
+  own word for it ("submit for review"), so the name now says what happens.
+  `extension_publish` keeps its name and its job. The error names in the
+  response follow: `DeployAuthError`, `DeployInputError`, `DeployConfigError`,
+  `DeployNetworkError` and `DeployError` are now `SubmitAuthError`,
+  `SubmitInputError`, `SubmitConfigError`, `SubmitNetworkError` and
+  `SubmitError`.
+- **Three tools were called inspect; now one is.** `extension_inspect` read a
+  built extension's files off disk, `extension_source_inspect` read a running
+  extension's live state, and `extension_dom_inspect` snapshotted one surface's
+  DOM. The name that reads as the primary one belonged to the static file
+  reader, which is the least of the three. Static analysis is now
+  `extension_analyze`, and the live-state tool takes `extension_inspect`.
+- **`extension_dom_inspect` is now `extension_dom_snapshot`.** It is not a
+  duplicate of the live-state tool and it survives the rename with its
+  capabilities intact, but sharing the word "inspect" was most of why the two
+  were confusable. The descriptions now state the split outright:
+  `extension_dom_snapshot` is the surface picker (it is the only tool that
+  reads an OPEN extension surface by name, the only one that takes a numeric
+  `chrome.tabs` id, and the only one that enumerates what is open) and it
+  returns a shallow snapshot over the CDP-free agent bridge, which needs
+  `allowControl: true`. `extension_inspect` is the deep reader (it is the only
+  tool that pierces CLOSED shadow roots, runs CSS selector probes, and
+  navigates a tab before reading it) and it rides the debugger protocol.
+
 ## 7.0.0
 
 `preview.extension.dev` is the only web door this package knows about. The

package/README.md

@@ -7,7 +7,7 @@
 
 # @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. 36 MCP tools that scaffold, run, inspect, debug, and publish cross-browser extensions.
+> Give your AI agent hands for browser extension development. 28 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="20.7%" />
 
@@ -102,19 +102,17 @@ cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/c
 | Tier | Tool | Description |
 | ---- | ---- | ----------- |
 | build | `extension_create` | Scaffold from a template |
-| build | `extension_list_templates` | Browse 60+ templates |
-| build | `extension_get_template_source` | Read template source files |
+| build | `extension_templates` | Browse 60+ 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 + preview |
-| run | `extension_preview` | Preview the production build |
+| 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_inspect` | Build output analysis |
-| see | `extension_source_inspect` | Live DOM inspection (CDP) |
-| see | `extension_dom_inspect` | CDP-free DOM snapshot |
+| 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, CDP-free |
 | see | `extension_list_extensions` | List loaded extensions (Chromium) |
 | see | `extension_logs` | Stream logs from every context |
 | see | `extension_doctor` | Diagnose the dev session leg by leg (ready contract, ports, token, executor, browser) |
@@ -123,26 +121,20 @@ cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/c
 | 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_install_browser` | Install a managed browser binary |
-| browsers | `extension_uninstall_browser` | Remove a managed browser binary |
-| browsers | `extension_list_browsers` | List managed browsers |
-| browsers | `extension_detect_browsers` | Detect system browsers |
-| platform | `extension_login` | Device login at extension.dev, stored token |
-| platform | `extension_whoami` | Show the stored login (never the token) |
-| platform | `extension_logout` | Remove stored credentials |
+| browsers | `extension_browsers` | Detect, list, install, and uninstall browsers |
+| platform | `extension_auth` | Device login at extension.dev, plus login status and logout |
 | 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_release_list` | List release channels and recent builds, to pick a valid build sha |
-| platform | `extension_deploy` | Submit to the Chrome, Firefox, and Edge stores through extension.dev |
-| platform | `extension_store_status` | Read a submission's outcome, credential health, and review state |
+| platform | `extension_submit` | Submit for store review: Chrome, Firefox, Edge, Safari, through extension.dev |
+| platform | `extension_release_status` | Read release channels, recent builds, and store submission and review state |
 
-Browser-launching tools (`dev`, `start`, `preview`) 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.
+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.
 
 ## 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. Sharing needs auth (`extension_login` or `EXTENSION_DEV_TOKEN`), the link expires, and `DELETE`ing the returned `revokeUrl` with the same token kills it early. Revocation is permanent and re-sharing mints a new link, so that `revokeUrl` is the only handle to the link you just made; every share is also appended to `.extension.dev/shared-previews.json` in the project (gitignored) so it survives losing the tool output. Without `share`, the tool returns a local-only deep link and uploads nothing.
+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. Sharing needs auth (`extension_auth` or `EXTENSION_DEV_TOKEN`), the link expires, and `DELETE`ing the returned `revokeUrl` with the same token kills it early. Revocation is permanent and re-sharing mints a new link, so that `revokeUrl` is the only handle to the link you just made; every share is also appended to `.extension.dev/shared-previews.json` in the project (gitignored) so it survives losing the tool output. 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.
 
@@ -150,7 +142,7 @@ That is a different job from shipping. Use `share` for the build you are holding
 
 ## From preview to store
 
-The platform tools connect agents to [extension.dev](https://extension.dev): `extension_login` 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_deploy` 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. After a real submission, `extension_store_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 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. 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/claude/ARCHITECTURE.md

@@ -88,7 +88,7 @@ Claude now knows:
 **Role in ecosystem:** Programmatic bridge between Claude and the extension.dev platform, sourced from the examples repo.
 
 ```
-Claude (via MCP) calls extension_list_templates({ surface: "sidebar", tags: ["ai"] })
+Claude (via MCP) calls extension_templates({ surface: "sidebar", tags: ["ai"] })
   │
   ▼
 MCP server fetches templates-meta.json (cached, 1hr TTL)
@@ -97,7 +97,7 @@ MCP server fetches templates-meta.json (cached, 1hr TTL)
 Returns: [{ slug: "sidebar-claude", ... }, { slug: "sidebar-transformers-js", ... }]
   │
   ▼
-Claude calls extension_get_template_source({ slug: "sidebar-claude", files: ["src/manifest.json", "src/lib/claude.ts"] })
+Claude calls extension_templates({ action: "source", slug: "sidebar-claude", files: ["src/manifest.json", "src/lib/claude.ts"] })
   │
   ▼
 MCP server fetches from https://raw.githubusercontent.com/extension-js/examples/main/examples/sidebar-claude/<file>
@@ -114,8 +114,8 @@ MCP server calls extensionCreate() → same go-git-it flow as CLI
 
 **How it integrates with the examples repo:**
 
-- `extension_list_templates` → reads `templates-meta.json` release asset
-- `extension_get_template_source` → reads raw files from the examples repo
+- `extension_templates` (`list`) → reads `templates-meta.json` release asset
+- `extension_templates` (`source`) → reads raw files from the examples repo
 - `extension_create` → clones from the examples repo (same as CLI)
 - `extension_add_feature` → sources codegen patterns from example templates
 - `extension_manifest_validate` → cross-references against known-good manifests in the catalog

package/claude/CLAUDE.md

@@ -195,9 +195,9 @@ extension inspect --tab 1 --include summary,html --with-console 20
 | `--max-bytes <n>`    | 262144  | Cap on returned HTML bytes                                                                     |
 | `--with-console [n]` | 20      | Also include the last n console lines for the target                                           |
 
-The `extension_dom_inspect` MCP tool wraps this verb one-to-one.
+The `extension_dom_snapshot` MCP tool wraps this verb one-to-one.
 
-**Debugging protocol (Chromium CDP): `extension_source_inspect` MCP tool.** Connects directly to the running session's debug port. Use it when the bridge is not enough: closed shadow roots (`deepDom`), selector probes, DOM snapshots, console summaries, or navigating the tab to a URL before inspecting. Returns structured events:
+**Debugging protocol (Chromium CDP): `extension_inspect` MCP tool.** Connects directly to the running session's debug port. Use it when the bridge is not enough: closed shadow roots (`deepDom`), selector probes, DOM snapshots, console summaries, or navigating the tab to a URL before inspecting. Returns structured events:
 
 - `page_html` - full injected HTML (after content scripts run)
 - `page_html_summary` - root/script/style/link counts

package/claude/README.md

@@ -62,7 +62,7 @@ Claude Code will automatically pick up the instructions and know how to:
 The [examples repo](https://github.com/extension-js/examples) publishes `templates-meta.json` as a nightly release asset. This file is the single source of truth for:
 
 - **CLAUDE.md**, references it so Claude knows all available templates
-- **MCP tools**, `extension_list_templates` fetches and queries it at runtime
+- **MCP tools**, `extension_templates` fetches and queries it at runtime
 - **`extension create`**, resolves template slugs to repo URLs via the same naming convention
 
 When a new template is added to the examples repo, all three layers pick it up automatically.

package/claude/commands/extension-add.md

@@ -20,7 +20,7 @@ Add a new feature surface to the current extension project. The user said: $ARGU
 2. **Get the reference pattern**
    If MCP tool `extension_add_feature` is available, use it. It returns the exact manifest additions, files to create, and reference template.
 
-   If MCP tool `extension_get_template_source` is available, read the reference template source to get real implementation patterns.
+   If MCP tool `extension_templates` (`action: "source"`) is available, read the reference template source to get real implementation patterns.
 
 3. **Update manifest.json**
    Add the required fields to `src/manifest.json`. Use the extension.dev cross-browser format:

package/claude/commands/extension-debug.md

@@ -13,7 +13,7 @@ Debug the currently running extension dev session. The user said: $ARGUMENTS
    - If no session: tell the user to start one with `/extension dev` or `npm run dev`
 
 2. **Inspect the live state**
-   If MCP tool `extension_source_inspect` is available:
+   If MCP tool `extension_inspect` is available:
    - Pass `include: ["html", "summary", "meta", "console", "extension_roots"]`
    - If the user provided a URL in `$ARGUMENTS`, pass it as `url`
    - If the user provided CSS selectors (strings starting with `#`, `.`, or `[`), pass them as `probe`

package/claude/commands/extension-publish.md

@@ -27,7 +27,7 @@ Default to `both` (Chrome + Firefox). If the user specifies `chrome` or `firefox
    ```
 
 3. **Inspect the builds**
-   If MCP tool `extension_inspect` is available, use it for each browser build.
+   If MCP tool `extension_analyze` is available, use it for each browser build.
    Check:
    - Total size under 10MB (store limit)
    - No source maps in production build

package/claude/commands/extension.md

@@ -11,7 +11,7 @@ Parse the user's intent from `$ARGUMENTS` and execute the matching action:
 
 ### "create <name>" or "new <name>", Scaffold a new extension
 
-1. If MCP tool `extension_list_templates` is available, use it to find the best template matching the user's description (check for surface type, framework, and keywords)
+1. If MCP tool `extension_templates` is available, use it to find the best template matching the user's description (check for surface type, framework, and keywords)
 2. If not, check the template catalog: `curl -sL https://github.com/extension-js/examples/releases/download/nightly/templates-meta.json | jq '.templates[] | {slug, description, uiFramework, surfaces}'`
 3. Run `npx extension@latest create <name> --template=<best-match>`
 4. Report what was created and suggest `npm run dev`
@@ -42,7 +42,7 @@ Parse the user's intent from `$ARGUMENTS` and execute the matching action:
 
 ### "debug" or "inspect", Debug a running extension
 
-1. If MCP tool `extension_source_inspect` is available, use it with `include: ["html", "console", "extension_roots"]`
+1. If MCP tool `extension_inspect` is available, use it with `include: ["html", "console", "extension_roots"]`
 2. If there's a URL mentioned, pass it as the target
 3. If there are CSS selectors mentioned, pass them as `probe`
 4. Report: injected HTML, console errors, extension root state
@@ -58,7 +58,7 @@ Parse the user's intent from `$ARGUMENTS` and execute the matching action:
 
 ### "template <query>", Search for a template
 
-1. If MCP tool `extension_list_templates` is available, use it with the query
+1. If MCP tool `extension_templates` is available, use it with the query
 2. Otherwise, search the catalog JSON
 3. Show matching templates with slug, description, framework, and surfaces