@extension.dev/mcp 10.4.3 → 10.8.0

package/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "extension-mcp",
       "source": "./",
       "description": "MCP tools for browser extension development: scaffold from 50+ templates, run the dev server with HMR, inspect the live DOM and logs, and publish store-ready builds for Chrome, Edge, and Firefox.",
-      "version": "10.4.3",
+      "version": "10.8.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 50+ 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": "10.4.3",
+  "version": "10.8.0",
   "author": {
     "name": "Cezar Augusto",
     "email": "hello@extension.dev",

package/CHANGELOG.md

@@ -1,5 +1,123 @@
 # Changelog
 
+## 10.8.0
+
+Some MCP actions change what a public channel serves or hand something to a
+store, and none of those can be taken back in place. The client now carries
+an approval gate for exactly those actions, so a human can stand between an
+agent's proposal and the write when the platform asks for one.
+
+- `extension_submit`, `extension_release_promote` and the destructive
+  `extension_shares` actions accept an `approvalId`. When the platform's
+  approval gate is on, the first call answers `approval-required` with an
+  approval id and a URL a human approves at extension.dev; the same call
+  repeated with that id performs the action. Rejections and pending
+  approvals answer as themselves, never as a bare error.
+- Approvals are bound to an action fingerprint, so an approval for one
+  promote cannot be replayed on another.
+- The gate is off unless the platform enables it; every existing flow is
+  unchanged by default.
+
+## 10.7.0
+
+The published client had no idea the platform could be held, so on the five
+lanes that run on our machines a reader met either a bare status code or an
+honest refusal that then sent them to a page answering 503. That is what
+makes someone conclude the product is broken.
+
+- A held lane now answers one shape on `extension_publish`,
+  `extension_release_promote`, `extension_submit`,
+  `extension_project_create`, `extension_shares`, `extension_preview_web`
+  and the registry reads behind `extension_release_status`: status
+  `platform-held`, `error.platformCode` set to `PLATFORM_NOT_OPEN`, and a
+  message carrying the condition, what still works, and a way back.
+- What still works is the part that was missing. Creating, developing and
+  packaging an extension run on your own machine, they are free forever, and
+  the hold does not touch them, so `extension_create`, `extension_dev`,
+  `extension_build`, `extension_manifest_validate` and `extension_doctor`
+  are named in the refusal and repeated in `value.stillWorks`.
+- A held refusal may not point at a held surface, so the only link it
+  carries is `templates.extension.dev`, the one surface that stays open,
+  and no refusal names a date.
+- Registry reads no longer collapse a non-ok response to
+  `<url> returned <status>`. The body is read once and its message travels
+  with the result, so a refusal the platform wrote reaches the reader
+  instead of a number. A held read is answered without buying an access
+  grant first, because a shut lane is not an auth problem.
+- The hold is recognised by the `code` field and the `x-extensiondev-hold`
+  header rather than by matching the sentence, so the wording can change on
+  the server without a client release.
+
+## 10.6.1
+
+Two reply strings pointed a stranger at surfaces the public hold keeps
+dark, so the remedy they named was a dead end wearing an instruction.
+
+- The closed-lane refusal in `extension_project_create` now relays the
+  server's own message verbatim whenever the server sends one, so the
+  platform decides what a caller reads there. The hardcoded console
+  pointer survives only as the fallback for a refusal that carries no
+  message field.
+- `extension_release_status` no longer promises that publicUrl links
+  need no login today. They are the public build pages and open without
+  login once the project is publicly reachable, and the console Builds
+  page is described as the authoritative record rather than a view the
+  caller is promised to see render.
+
+## 10.6.0
+
+The server covered every stage of the lifecycle except the one an agent
+needs most. It could read anything, so every expectation had to be
+hand-rolled as a string of JavaScript over a blob, which is the guessing
+the paired skill exists to prevent.
+
+- `extension_assert` is the test stage: a list of expectations in, one
+  verdict each out. Five checks ship, `background-worker-booted`,
+  `surface-rendered`, `content-script-injected`, `storage-key-present`
+  and `console-errors-empty`, and the run is a pass only when every one
+  of them passed.
+- A check that the platform cannot cover comes back `inconclusive`, never
+  a pass and never a red against the extension, and carries a `settledBy`
+  naming the evidence that would answer it. A content script's execution
+  is not observable from outside its isolated world, so a declared
+  `content_scripts` match is inconclusive rather than a pass; an absent
+  MV3 worker target is inconclusive because Chrome delists an idle one;
+  zero errors over a session that never wrote a log line is inconclusive
+  because zero errors and zero events are the same number; a read the
+  platform refuses, such as `chrome.storage` without `allowControl`, is
+  inconclusive because nothing was learned about the extension.
+- The verdict document is a port of the preview lane's own contract, with
+  its own contract name and check registry so the two can never be
+  confused, and each check names the preview check it is the
+  live-browser counterpart of. A contract test pins the outcome
+  vocabulary, the check and document shapes, and the aggregation rule
+  against that package's own code whenever a monorepo checkout is
+  reachable, the way the STORE.md corpus pins its parser.
+- The manifest candidate list, which `extension_open` held three copies
+  of, moves to one reader that every caller shares.
+
+## 10.5.0
+
+`extension_submit`'s STORE.md advisory and the platform parser that feeds
+AMO and Partner Center disagreed, and the disagreement ran in the
+dangerous direction: the advisory stayed silent about notes the
+submission would never carry.
+
+- The hand-rolled section and field probing in `extension_submit` is
+  replaced by `src/lib/store-md.ts`, an exact port of the parser the
+  submission runs. Headings the platform ignores, such as
+  `### AMO reviewer notes` or a Firefox-naming Edge section, now raise
+  the warning they always should have.
+- A contract corpus of 14 STORE.md fixtures and a pin generated from the
+  platform parser hold the two implementations together: the pin carries
+  the upstream file's sha256 and its answer for every fixture, and the
+  suite replays both parsers over the corpus whenever the upstream
+  checkout is reachable. Neither side can move alone.
+- When the notes are found, the advisory now names the file it read and
+  says the submission reads STORE.md from the source repository at the
+  built commit, so an uncommitted edit is never mistaken for a
+  submission that carries it.
+
 ## 10.4.3
 
 Four truths an agent reads got sharper. A share recorded twice is one

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. 28 MCP tools that scaffold, run, inspect, debug, and publish cross-browser extensions.
+> 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="20.7%" />
 
@@ -117,12 +117,14 @@ cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/c
 | 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 |
@@ -132,6 +134,45 @@ cp node_modules/@extension.dev/mcp/claude/commands/*.md ~/my-extension/.claude/c
 
 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.
+
 ## 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.