# Mercemur MCP Mercemur speaks [MCP](https://modelcontextprotocol.io) at a single endpoint: `https://mcp.mercemur.com/mcp` Point any MCP client at it, Claude Desktop, an IDE, another agent, and it can read your catalogue, write prices, edit page templates, rearrange your Online Store layout, and ask your Optimize and Sales assistants questions, all under the same scope model as the [REST API](/api-reference/introduction). A single `tools/list` covers everything below: catalogue, content, design, media, and the two assistants. Which tools a connection actually sees is bounded by its scopes, the same as an API key. Every content and design write lands in a draft. Nothing reaches a shopper until a separate publish call. Preview first; a merchant should see a page before it goes live. ## Connect Two ways in, dispatched by the credential's own shape, not by a setting you choose: Point your client's MCP connector at `https://mcp.mercemur.com/mcp`. It discovers the authorization server automatically (RFC 9728 protected resource metadata) and opens a browser consent screen. The consent screen is where a merchant picks **which store** the agent may act on and **which scopes** it gets, the same store-and-scope decision an API key makes at creation time, just made by a person in a browser instead of in the dashboard. This is a Mercemur-run authorization server, not a third-party identity provider: the credential MCP needs is a (store, scopes) pair, and only a Mercemur consent screen can make that call. Send the same `sk_...` key you'd use against the REST API as a bearer token: ``` Authorization: Bearer sk_live_... ``` No separate MCP credential to create. The key's scopes are exactly what governs which tools it can list and call; see [Scopes](/authentication/scopes). **An MCP client reads its tool list once, when it connects.** Tools added to Mercemur after that will not appear until the client reconnects, even if the connection's scopes already cover them. If a tool you expect is missing, reconnect before assuming it is unavailable. ## Call this first ### get_commerce_schema Returns the storefront template contract: every object and property a template can bind to, the binding syntax, the island components, and the capability envelope (what CSS and HTML are available, and what is not). Call this before writing any template. **Scope:** `read_storefront` · takes no arguments. The template language has no render errors, a mistyped binding renders as empty rather than failing, which is exactly why this comes first: there is nothing else that will tell you a binding is wrong. ## The tool groups Products, variants, prices, and collections. Create, price, publish, group. Page templates: read the draft, preview a render, publish, and undo a bad publish. Blog posts and categories: write one, edit it, publish or archive it. The Online Store builder: sections, navigation, theme tokens (colour, font), starter designs. Upload an image or register one already hosted elsewhere into the media library. Draft a broadcast, count the list, and send it. The only group here whose writes cannot be undone. Ask the store's own Optimize and Sales assistants a question directly. ## What theme tools change, and how far it reaches Two different tools change two different things, and they do not overlap: - **`update_theme_settings`** (colour, font) is **store-wide**. It sets CSS custom properties at the storefront's root layout, so a colour change is live on every page the moment it publishes, not one page at a time. - **`update_template`** changes **one page**. Editing the product page template does not touch the home page template; each is its own draft with its own publish. - **`write_island_styling`** covers the shared header/footer components (cart drawer, search, nav menu, currency switcher) that appear on every page by design, plus their animation timing and easing. None of the tools here reshape a component's own structure, a dialog's size or whether it is a drawer or a centered modal is fixed in the component, not a token. Styling tunes what exists; it does not redesign it. ## Scopes Every tool is gated by the same scope vocabulary the REST API uses; see [Scopes](/authentication/scopes) for the full list. A connection only sees, and can only call, the tools its scopes cover, the same "no tool a caller cannot use is even advertised" rule the REST API enforces with a 403. ## Narrowing a connection to fewer tool groups Scope answers *is this caller allowed to*. A second, independent dimension answers *does this caller want to*: `?features=` on the connection URL keeps a client's tool list down to the groups you actually pick, so an agent doing design work never carries the catalogue tools in its context. ``` https://mcp.mercemur.com/mcp?features=design,content ``` Comma-separated group names from the same set the [tool groups](#the-tool-groups) above use: `catalog`, `content`, `design`, `marketing`, `media`, `schema`. Omit the parameter, or leave every group selected, and a connection sees everything its scopes allow, exactly as if `features` were never named. This narrows and nothing more. A group your scopes do not cover stays hidden whether or not you name it, `features` can never grant authority a scope withheld. The dashboard's connection screen builds this URL for you as you tick and untick groups, so hand-editing it directly is rarely necessary, but any client can set it on its own connection URL. A tool group named here that Mercemur has never published (a typo, a group renamed since) is not ignored. If every group you named is unrecognised, the connection narrows to **nothing** rather than falling back to the full list, a filter that fails open on a typo would defeat the reason to have one.