MCP for partners and developers (mcp-dev)

MCP for a partner — someone who builds plugins or themes for Orbit — has two halves. While you build, a small server on your own machine gives your coding assistant the real Orbit API contract: every endpoint, every schema, and these guides. No account, no API key, no store data. For your partner account, the hosted MCP endpoint gives the assistant you already use a view of what you have published: your plugins and themes, their review status, your earnings and your payouts.

Neither half reaches a merchant's store. Reading or changing a real store is the merchant connection, which the merchant approves from their own admin.

Part 1 — While you build: the developer server

What it is, and what it is not

@orbitcommerce/mcp-dev is an MCP server for the assistant that helps you write an integration: Claude Code, Claude Desktop, Cursor, or anything else that speaks MCP. It answers questions like "what scopes does creating a product need?", "show me the fulfilment endpoint", or "what fields does the product create body take?" from the published OpenAPI document, so the assistant works from the endpoint contract instead of guessing at it.

It is read-only and unauthenticated. It holds no credentials and cannot read or write any store's data, nor your partner account — that is Part 2.

Install

The package is published on npm and runs with npx, so there is nothing to clone or build.

Claude Code

claude mcp add orbit-dev -- npx -y @orbitcommerce/mcp-dev

Claude Desktop, Cursor and other clients — add it to the client's MCP configuration:

{
  "mcpServers": {
    "orbit-dev": {
      "command": "npx",
      "args": ["-y", "@orbitcommerce/mcp-dev"]
    }
  }
}

Restart the client and the six tools below appear in its tool list.

Tools

A useful working pattern: ask the assistant to call list_api_resources once at the start of a session, then let it pull individual endpoints and schemas as it writes code. The contract it sees is the one the API currently publishes, so a field it names exists.

Where the answers come from

Nothing is vendored into the package.

• The API reference is fetched from https://api.myorbitcommerce.net/v1/openapi.json on first use and cached in memory for ten minutes, so the server always reflects what production currently publishes — the same document that powers the API reference on this site.
• The guides are read from this site's /raw/ directory over HTTP, byte-for-byte what the pages render, and the guide index comes from /raw/guides.json so titles and summaries cannot drift from the listing you see here.

If the site is unreachable, list_developer_docs falls back to a built-in guide list so listing still works, and get_developer_doc reports the URL it could not reach rather than failing silently.

Configuration

Both variables are optional; the defaults point at production.

Set them in the client's MCP config ("env": { … }) or in the shell that starts the client.

Part 2 — Your partner account: the partner connection

A partner connection is bound to your partner account and to no store, ever. It cannot read or change any merchant's store, and it is not the affiliate's dev-store connection either (see MCP for affiliates).

Connecting

The same hosted server and the same OAuth 2.1 flow as every other Orbit MCP connection, at the partner endpoint:

https://api.myorbitcommerce.net/mcp/partner

In your assistant, add Orbit as a connector (Claude and ChatGPT call this Connectors, Integrations or Apps) and paste that address. The path is what makes the connection a partner one before anyone has signed in: its discovery document advertises the partner scopes, and your assistant sends the address back when it starts the OAuth flow, so Orbit opens the partner dashboard's consent screen rather than a store login. (The bare /mcp is the merchant endpoint; /mcp/affiliate the affiliate one.) You sign in if you are not already, see the client's name from Orbit's own registration record, tick what you are happy with, accept the data terms, and Approve. Your assistant receives a token bound to your partner account.

Settings → AI Assistants in the partner dashboard shows the same address, every assistant you have connected with its permissions, and a Revoke button. Revoking takes effect on the assistant's very next request.

Permission tiers and scopes

The partner consent screen uses the same three tiers as the merchant screen, on the same rule: what does the handler do. Reads are tier 1 and always on once granted. A draft nobody can install is tier 2, behind the "Safe changes" switch. Anything that submits, publishes, prices, replies in public or changes what a merchant can install is tier 3, behind the "Live and permanent changes" switch — and every tier-3 tool also asks you to confirm in your own next message before it runs.

These scopes are only ever granted to a partner connection. A merchant's consent screen never offers them, an affiliate's never offers them, and a store API key can never hold them. Conversely a partner connection is never granted a store scope: it has no store to spend one on.

You can only grant what your own role in the partner account allows: each scope corresponds to the permission the partner dashboard uses for the same action, and the consent screen offers only the scopes your permissions cover. If an assistant asks for more, it receives the intersection — a colleague who cannot submit a plugin from the dashboard cannot hand an assistant partner-plugin:submit either.

The endpoints, for reference

Everything the tools do is a call under /v1/partner, reachable only with a partner connection's token — a merchant or affiliate token, a store API key or a plugin token gets 403. The partner is always derived from the credential, never from a parameter, and every write runs the same code the partner dashboard's own button runs, so the two cannot disagree on what a submission needs or who may publish.

Because a partner connection has no store, any store-scoped /v1 route refuses it with 403 and a message naming /v1/partner — so a token that leaks can reach your account, and nothing else. Two writes act as a person rather than as the account: an install link records the user who approved the connection as its creator, and a theme publish carries the same email-verification requirement as the dashboard's Publish button, checked against that user.

What the assistant sees

Call tools/list after connecting rather than hard-coding names. A partner connection is offered the partner tools and nothing store-shaped; which ones depends on the scopes you granted.

Reads (tier 1): list_my_plugins, get_my_plugin, list_my_plugin_plans, list_plugin_install_links, list_plugin_reviews, list_my_themes, get_my_theme, list_my_theme_versions, get_my_published_theme, partner_earnings_overview, partner_earnings_over_time, partner_top_products, partner_transactions, partner_payout_balance, list_partner_payouts. Ask things like "which of my plugins are still in review?", "why was Acme Feeds rejected?", "what did I earn this quarter and from what?" or "is there anything to pay out?". Statuses come back in words — "in review by Orbit", "rejected — see the reason" — and a rejected plugin leads with the reviewer's reason.

Drafts (tier 2, no confirmation): create_plugin_draft, update_plugin_draft, create_theme_draft, update_theme_draft, cancel_theme_review. These cannot touch a live listing: asked to edit a plugin that is live or in review, the assistant is refused and told to use the dashboard. Screenshots, icons, a plugin's code integration and a theme's templates are still set up in the partner dashboard; the assistant handles the listing text and the lifecycle.

Live changes (tier 3, confirmed every time): submit_plugin_for_review, publish_plugin_unlisted, set_plugin_visibility, create_plugin_install_link, revoke_plugin_install_link, reply_to_plugin_review, create_plugin_plan, update_plugin_plan, archive_plugin_plan, set_plugin_plan_price, deactivate_plugin_plan_price, submit_theme_for_review, create_theme_version, publish_theme, unpublish_theme, rollback_theme. Before any of these runs, the assistant reads the plugin or theme, then puts the change to you by name — "Acme Plugins (partner account): publish without review the plugin "Acme Feeds" (acme-feeds). This plugin is draft, visibility unlisted. Live the moment you say yes. Any merchant with the direct address or an install link can install it…" — with what puts it back, or that nothing here can (a submitted plugin cannot be withdrawn by the assistant; a revoked install link cannot be restored). Only your yes in your next message runs it. An install link's address is shown once, in the result, and never in the prompt.

Some refusals happen before you are even asked: a public plugin cannot be self-published or given an install link (public goes through review), a theme that has never been approved cannot be published (its first publication goes through review and Orbit's approval; after that you publish versions yourself), and a visibility already in place is a no-op.

Reference

• MCP at Orbit — the map of every MCP surface
• MCP for merchants — the merchant-facing connection, and the tier and confirmation model the partner connection reuses
• MCP for affiliates — dev stores for affiliates who build for clients
• API reference — the document the developer server serves
• Scope catalog — what get_developer_doc returns for scope-catalog
• @orbitcommerce/mcp-dev on npm