@extenshi/mcp

A Model Context Protocol server that brings the Extenshi extension catalog — search, security analysis, market research, and pre-publish scanning — into your AI tools (Claude Code, Claude Desktop, Cursor, …).

It runs locally over stdio, so there's nothing to host. It reuses your existing Extenshi API key (the same one @extenshi/cli uses) and talks to the public Extenshi backend on your behalf.

Get an API key

An API key is required for catalog and own-project tools. Documentation, templates and static workflow guides, including get_development_guide, work without a key. The backend enforces access and project entitlements for authenticated operations.

1. Sign up at https://auth.extenshi.io/signup**
2. Create a key at https://dojo.extenshi.io/api-keys**
3. Provide it via the EXTENSHI_API_KEY environment variable (or run npx @extenshi/cli@latest login, which the MCP server reads from ~/.extenshi/config.json).

Configure your MCP client

{
  "mcpServers": {
    "extenshi": {
      "command": "npx",
      "args": ["-y", "@extenshi/mcp@latest"],
      "env": { "EXTENSHI_API_KEY": "ek_…" }
    }
  }
}

Plan the whole lifecycle

Call get_development_guide first for the complete tool inventory on this connection, the Extenshi service directory, prerequisites and documentation links, GitHub source/CI guidance, and the ordered plan through implementation, testing, store release and maintenance. The inventory is built from registered tools. The remote connector shares this guide and directs local artifact operations to stdio or CLI. See the development workflow.

Tools

In a client that shows MCP Apps, show_build_map draws the map in the conversation (the page ui://extenshi/build-map). The page calls three app-only tools, build_map_view, build_map_answer and build_map_file; the server keeps them from any client that does not advertise io.modelcontextprotocol/ui.

Identifying an extension by its store id

get_extension, get_reviews, get_security and scan_extension accept either the numeric catalog extension_id or the extension's store_id — the id straight from the store URL, which is usually the only precise identifier you have:

{ "store_id": "cjpalhdlnbpafiamejdnhcphjbkeiagm", "store": "CHROME" }  // Chrome/Edge: `store` required
{ "store_id": "dark-reader" }                                          // Firefox: unambiguous

store is required for a Chrome/Edge id because both stores use the identical 32-character format; Firefox ids (slug, GUID, or email-style) route automatically. Resolving a store id is free — only the read that follows costs a credit.

Credits

Every account gets a one-time free allowance of 10 reads and 3 scans (no card required). Beyond that, buy prepaid credit packs (up to 10,000 reads and 1,000 scans per pack) that never expire. Call get_credit_balance (free) to check what's left before running a large batch. Manage credits at https://dojo.extenshi.io/billing.

Configuration

The backend endpoints are compiled into the package and always point at production — only the API key is read from the environment.

Develop

yarn build            # tsc -> dist/
# Inspect locally:
EXTENSHI_API_KEY=ek_… npx @modelcontextprotocol/inspector node dist/index.js

Releases are staged on npm by CI and approved manually by a maintainer with 2FA; ./scripts/publish.sh is the local staging fallback (DRY_RUN=1 ./scripts/publish.sh to validate). Staging requires Node ≥22.14 and npm ≥11.15.

See the project synchronization workflow for CLI commands, revision conflicts, evidence freshness and OAuth recovery.

Standalone Pay applications

These tools require a backend with standalone Pay support. A development project is optional. Request explicit pay.read and/or pay.write OAuth scopes, or grant Pay permissions to a local API key in API keys. Older credentials have no Pay access. Tool registration does not prove backend rollout or SDK npm publication.

Owner approval on the hosted connector

On the hosted connector (OAuth sign-in), the changes that move money or publish to the public are proposals, not immediate edits: set_pay_enabled, upsert_pay_offer, archive_pay_offer, archive_pay_app, set_pay_seller_profile, set_pay_trial, update_uninstall_offer, publish_privacy_policy and set_legal_translations (the privacy policy and the license terms). Each returns status: "pending_approval" with an approvalId and an approvalUrl. Nothing changes until the owner opens the link in Dojo and approves it; get_approval reports the outcome. A proposal expires after 24 hours (72 for a policy), and a newer proposal for the same thing replaces an older one. For a policy or a translation, the text is stored with the proposal, so the owner approves exactly the words that get published; a translation is also refused if its English text changed in between. An offer edit that names only some fields is stored with the offer's other terms as they were when it was proposed, price and paywall order included, so the owner approves every term it will save.

A local ek_ API key from API keys acts directly, as before: whoever holds it is the owner's own tooling. With a key, these tools change the live state at once and return no approvalId, and their descriptions on the local package say so. The one exception is request_license_terms_publication, which asks the owner on either connection. No tool deletes a project or an extension.

The author completes legal acceptance and Stripe KYC in the browser. Read get_pay_readiness before enabling checkout; enablement, key rotation and offer changes require explicit author authorization. Export pages contain private financial data and must remain in an author-controlled destination. Only the publishable SDK key belongs in an extension, never a developer API key or Stripe secret.