# Muse connectors decoded: Meta's directory vs open MCP

Meta opened Muse connectors to developers on 18 September and logged more than 1,500 applications in under a week, then named Walmart, Sephora, Shop Pay, PayPal, GitHub and Notion among the next partners. The directory is a Meta-reviewed channel with an unpublished fee, custom connectors are unreviewed, and MCP is the durable integration to build first, before you fill in the Muse form.

- Published: 2026-09-26 · Category: AI & Cloud Infrastructure · Tags: Meta Muse, MCP, AI Agents, Agentic Commerce, Connectors, Agent Security, Shopify, Stripe, Muse Series
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/muse-connectors-decoded-meta-directory-vs-open-mcp

Meta opened Muse connectors to outside developers on 18 September 2026. Five days later, at Connect, chief AI officer Alexandr Wang said more than 1,500 applications had arrived in under a week. The same day Meta named the next wave of partners: Walmart, Best Buy, American Eagle Outfitters, DICK'S Sporting Goods, Fanatics, Gap, Michael Kors, Sephora, Ulta and Wayfair on the retail side, Shop Pay and PayPal for payments, Instacart for groceries, Expedia coming soon, and Notion, Granola, GitHub and Box for work. Zuckerberg's pitch to developers was four words: "You bring the API." If your team has spent the past year building MCP servers, the question is what a Muse connector actually is, how far it is from MCP, and whether you should build one.

![Mark Zuckerberg on stage at Meta Connect 2026 with arms spread in front of a lit bookshelf backdrop](/images/blog/muse/connect-2026-header.jpg)
Mark Zuckerberg at Connect 2026, where Meta named the next wave of Muse connector partners. Image: Meta press materials.

**Part 2 of 4 on Meta Muse.** [Part 1](/en/blog/meta-muse-first-mass-market-personal-agent-decoded) covered what Muse is, the Secure VM and Sentinel architecture, pricing and launch numbers. Today: the connector system, how it compares with MCP, the checkout rails, and what a merchant or SaaS vendor should build. Part 3 puts Muse next to Hermes Agent and OpenClaw. Part 4 covers the EU availability gap.

## Three things Meta calls a connector

Meta's Help Center, its security post and its developer site use the word "connector" for three different mechanisms. Keep them apart, because the review, the risk and the reach differ for each.

**Directory connectors.** These are the ones Meta lists in Muse settings. Meta built the first set itself (the Help Center names Gmail, Google Workspace, Apple Health and Android SMS, and says Facebook, Instagram and Threads connect automatically when the accounts sit in the same Accounts Center). Partners submit the rest through muse.ai/platform. The submission page describes a three-step path: describe what the connector does, pass a review for "functional, security, and legal requirements" with end-to-end testing by Meta, and appear in the directory, where editorial review decides featured placement. The page publishes no protocol, no SDK, no fee structure and no timeline.

**Custom connectors.** If a service is not in the directory, the user can ask Muse to connect it anyway. Muse writes the integration itself against whatever the service exposes, an API or a command-line tool, walks the user through obtaining credentials and stores them. Meta does not look at the result. The Help Center is explicit: Meta does not review custom connectors or how they use your information, so grant access with caution and review the provider's privacy policies. Read that sentence twice if you sell software. Your API is already a Muse connector, whether or not you applied.

**No connector at all.** Everything else runs through the browser in the user's Secure VM. Muse reads the page, fills in the form and pays with a one-time card. This is the path Amazon has blocked, and it is the path most Swedish web shops will meet first.

There is a fourth thing with the same name, and it causes confusion. Meta for Developers runs a separate "Meta AI Connectors" developer preview at dev.meta.ai. That programme targets the Meta AI app, the web and AI glasses, not Muse. It accepts "a live REST API (or one in active development)", offers onboarding through a guided UI "or MCP onboarding", admits developers in waves, and says publishing is "coming in a later phase". Meta has not said whether the two directories will merge. Until it does, treat them as two applications.

## How a connector runs inside the VM

Meta's security post from launch day, published at research.meta.ai, describes the connector runtime in more detail than most enterprise agent vendors publish. The design is worth copying, and it is also the sharpest available contrast with how MCP tools usually run.

- **Connector logic runs outside the agent's runtime cell.** Meta uses privilege separation. A connector's command-line tool inside the cell only parses arguments, opens files the caller may already access, and passes typed arguments and file descriptors over a Unix socket to a worker outside.
- **The model never holds a real credential.** A service Meta calls authd mints surrogate tokens. The real token is swapped in at the network boundary, after Sentinel has approved the action. Meta's wording: "any attempt to coerce the agent to reveal the actual secrets via prompt-injection or otherwise is futile."
- **Three separate decisions.** Privilege separation decides which code may hold credentials at all. authd decides which credential a given caller can receive, so "a calendar worker cannot ask authd for an email credential simply by changing a request parameter." Sentinel decides whether the action may proceed, routes it to allow, deny or ask, and generates a user-visible purpose for the request.
- **Built-in connectors carry their own filters.** The email connector strips one-time codes, password reset links and login magic links before the model sees the mail, using both deterministic rules and classifiers.

Now compare the protocol side. The MCP specification's own security section says hosts must obtain explicit consent before invoking any tool, then adds that "MCP itself cannot enforce these security principles at the protocol level." Meta's Muse Code documentation, for its own developer product that does support MCP, says the same thing more bluntly: "MCP tools are not sandboxed. Unlike shell commands, an MCP server runs as an ordinary child process (stdio) or a direct network connection, outside the filesystem and network sandbox. Approval still applies, but containment does not."

So Meta ships MCP where the user is a developer who can be trusted to read a warning, and ships a reviewed, privilege-separated connector model where the user is a consumer who cannot. That is a defensible split. It also tells you what Meta thinks of the average MCP deployment, and if your internal agents run MCP servers with long-lived tokens in environment variables, Meta has a point.

| Control | Muse connector runtime | Typical MCP host today | What to build on Azure |
| --- | --- | --- | --- |
| Where the tool code runs | Separate worker outside the agent cell | Child process or remote server, no containment | Remote MCP servers in Container Apps, one per trust domain |
| Who holds the token | authd; model sees a surrogate | Host config or env var; model-adjacent | Entra Agent ID plus Key Vault, short-lived tokens per call |
| Approval gate | Sentinel, a separate agent, allow/deny/ask | Host UI prompt, often auto-approved | Policy service outside the model with an audit log |
| Scope per connector | Read-only or act, set by the user | Whatever the OAuth client asked for | Separate read and write tools with separate scopes |
| Inbound content filtering | Per-connector filters plus injection classifiers | None by default | Strip secrets and links from tool results before they reach the model |

## A curated directory versus an open registry

The Muse directory and the MCP ecosystem solve the same problem, letting an agent reach a third-party service, from opposite ends. One is a distribution channel owned by a single company. The other is a protocol with a metadata registry that deliberately refuses to curate.

| Dimension | Muse connector directory | MCP (spec 2026-07-28) and the MCP Registry |
| --- | --- | --- |
| Protocol | Unpublished. You describe an API; Meta builds and tests the integration | Open JSON-RPC spec, stateless HTTP transport, tools, resources, prompts, elicitation |
| Getting listed | Meta review: functional, security, legal, end-to-end test; editors pick featured placement | Namespace proof via GitHub, DNS or HTTP challenge; no security scan; registry is in preview |
| Who curates | Meta | Nobody at the registry; downstream marketplaces may add ratings and curation |
| Who runs the code | Meta, inside the user's VM, calling your API | You host the server; the host application connects to it |
| Credentials | Held by Meta's authd; user grants per-connector scope in Muse settings | OAuth-based authorization spec; tokens held by the host application |
| Reach | Muse users in the US and Canada | Every MCP host: Claude, ChatGPT, Copilot, Cursor, Muse Code, your own agents |
| Business terms | Unpublished; Meta says it will take a small fee from transactions | None; you pay your own hosting |
| Private or internal services | Not applicable | Supported, though the public registry excludes private servers |

The registry row is not a criticism of MCP. The registry documentation says its metadata is "deliberately unopinionated" and that security scanning is delegated to npm, PyPI, Docker Hub and downstream aggregators, which is the right design for an open protocol and the wrong one for a consumer app. The reach row should drive your decision. One MCP server serves every host that speaks the protocol, including Meta's own Muse Code. One Muse directory connector serves Muse, in two countries, after a review whose length Meta has not published.

If you have been following our MCP coverage, from [the stateless spec migration](/en/blog/mcp-goes-stateless-what-the-2026-07-28-spec) to [the roadmap after it](/en/blog/stateless-mcp-and-what-s-next-how-the-2026), the practical conclusion is the one you would expect: build the MCP server first, because it is the durable asset, and treat the Muse directory as a submission form you fill in afterwards with the same API behind it.

## The checkout rails, and who is not on them

Connectors let Muse read and write. The payment rails let it buy, and they are where Meta's revenue comes from. Three rails went live within sixteen days of launch.

| Rail | Announced | What it covers | Mechanism |
| --- | --- | --- | --- |
| Link by Stripe | 8 September (Stripe newsroom) | "Over 1 million businesses that accept Link"; US consumers only | Saved payment method at Link merchants; elsewhere "a single-use virtual card to Muse, limited to the approved purchase". User approves each amount in the chat |
| Shop Pay | 22 September (Shopify, via Yahoo Finance) | Tobias Lütke: "agentic checkout with Shop Pay on all Shopify stores" | Shop Pay's stored payment and shipping details; Muse already had the Shopify catalogue at launch |
| PayPal | 22 September on X, reported 24 September | "PayPal merchants worldwide" | PayPal checkout inside Muse; PayPal separately announced WebMCP support this month, as reported by The Paypers |
| Amazon | Blocked, 22 September (Fortune) | The largest US retailer | "continued access by an unauthorized AI agent violates Amazon's Conditions of Use"; Amazon says Meta never asked, and runs its own Buy for Me agent |

Zuckerberg's line at Connect, quoted in Part 1, was that Meta expects "over time we will profit by taking a small fee from transactions." Neither the platform page nor the partner announcements put a number on that fee. A merchant who joins the directory is therefore joining a channel with an unpublished commission, on the strength of a distribution base that reached number one on the US App Store in ten days. Affiliate networks and marketplaces have always asked for the same trade. The difference is that the agent, not the shopper, decides which merchant to open.

## Four postures for a merchant

Every business with a web shop now has to pick one of four positions. Not choosing is choosing the third one.

- **1. Join the directory.** Submit through muse.ai/platform, pass review, accept the fee when it is published. You get discovery inside the agent and a first-class connector instead of a browser session. Cost: an API Meta can call, legal review of Meta's terms once they exist, and upkeep when your catalogue changes. Right for merchants with a large US consumer share.
- **2. Be reachable through a rail you already have.** If you run on Shopify with Shop Pay, or accept PayPal or Link, Muse can already check out at your store without you doing anything. The cost is zero. The risk is that you find out from the order feed, not from a decision.
- **3. Stay a website and let the browser in.** Muse's VM browser will shop your site like a careful human. Keep forms machine-friendly, keep prices and stock in the HTML rather than behind a click, and expect some support tickets to come from an agent's mistake rather than a customer's.
- **4. Block, as Amazon did.** Detect the agent and refuse it. Amazon can afford that because customers go to Amazon anyway. A Swedish niche retailer refusing agent traffic is refusing a channel its competitors on Shopify have by default.

## If you sell software, prepare for both kinds

A SaaS vendor faces the custom connector problem before the directory one. A Muse user in the US who wants your product connected will ask Muse, and Muse will read your public API documentation, request a key and write the integration. You will not be consulted. Your API terms, rate limits and OAuth scope design are the only levers you have. Our post on [building reliable agent tools](/en/blog/building-reliable-agent-tools-schemas-idempotency-recovery) covers the engineering; here is the shorter list that matters for Muse specifically.

- **Split read from act at the scope level.** Muse offers users a read-only setting per connector. If your OAuth scopes do not separate reading a record from changing it, the user cannot make that choice and your data gets the wider grant.
- **Make every write idempotent.** An agent that lost a response will retry. An idempotency key on create and update calls is the difference between one invoice and three.
- **Decide what agent traffic is allowed to do in your terms of service.** Amazon's block rests on its Conditions of Use. Your terms probably say nothing about an authorised user delegating to an agent. Say something, either way.
- **Ship an MCP server with the same surface.** It is the same API behind a documented protocol, it reaches every other agent host today, and it is the integration you will point Meta at if the connector preview's MCP onboarding path becomes the standard route into Muse.
- **Then apply to the directory**, with the MCP server and the API docs as the description. The application is a form, not a project.

## The Swedish and EU angle

Muse is available in the US and Canada. A Swedish consumer cannot install it, and a Swedish company cannot test its own connector as a user. The connector economy still reaches Sweden, through the rails. PayPal's announcement covers merchants worldwide, and Shopify's covers all Shopify stores. A Swedish web shop on Shopify with Shop Pay, or one that accepts PayPal, can receive an order placed by a Muse agent for a customer in Texas today, with cross-border shipping and Swedish VAT handled by whatever your checkout already does. Klarna and Swish are not on any list Meta has published, which means the two rails Swedish shoppers actually use have no agent path yet, and a Swedish customer's agent, when Muse arrives here, will find Link and PayPal first.

On the data side, a directory connector means Meta's infrastructure, in the US, calls your API on behalf of a US resident. For a Swedish SaaS vendor that is an ordinary export of the user's own data at the user's request, and your existing US customer terms already cover it. The harder case is the custom connector inside a company. An employee in Stockholm with a Muse account, once Muse launches here, can hand Meta's VM an API key to the company's project tool and let the agent work. Meta reviews none of it. That is the shadow IT pattern from Part 1 with an API key attached, and the right response is a policy now, not a discovery later.

Your own MCP servers do not have this problem. A remote MCP server in Azure Container Apps in Sweden Central, fronted by Entra Agent ID, stays under your control, serves Copilot and Claude today, and leaves the Muse question as a submission form you can file when Meta's terms are public and the EU launch date is known. Part 4 covers the Meta Model API side of that gap, where there is still no EU availability, no data processing agreement and no residency option on the record.

## What to do this week

- **Check your order feed** for Shop Pay or PayPal orders with US shipping addresses placed since 22 September. Some of them may already be agent-placed. Decide whether you want more.
- **Pick a posture** from the four above and write it down, including who owns the decision when Meta publishes the fee.
- **Audit your public API** as if Muse were about to read the docs, because it is: scope granularity, idempotency, rate limits, and a terms-of-service sentence about delegated agents.
- **Copy the runtime design.** Surrogate tokens, a policy gate outside the model, per-connector read or act scopes, and secret-stripping on inbound content. Meta published it; your internal agent pilots can adopt it without waiting for Muse.
- **Build the MCP server before the Muse application.** It is the same work and it serves every other agent host now.

## Sources

- [Meta: Everything we announced at Meta Connect 2026 (23 September 2026), connector partner list](https://www.meta.com/blog/meta-connect-2026-everything-we-announced/)
- [Muse platform: connector submission and review steps](https://muse.ai/platform)
- [Meta Help Center: How Muse works with connectors (directory vs custom connectors)](https://www.meta.com/help/artificial-intelligence/1687253048996149/)
- [Meta: Security and safety for AI agents, our approach with Muse (8 September 2026)](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse)
- [Meta for Developers: Meta AI Connectors developer preview](https://dev.meta.ai/products/connectors)
- [Meta for Developers: Muse Code, extending with MCP servers](https://dev.meta.ai/docs/muse-code/extending)
- [TechCrunch: Everything new coming to Meta's AI agent Muse (23 September 2026), 1,500 applications](https://techcrunch.com/2026/09/23/everything-new-coming-to-metas-ai-agent-muse/)
- [Mark Zuckerberg on X: opening Muse connectors to developers (18 September 2026)](https://x.com/finkd/status/2101084678640066765)
- [Stripe newsroom: Stripe helps Muse shop across the internet with Link (8 September 2026)](https://stripe.com/newsroom/news/stripe-helps-meta-muse-shop-with-link)
- [Yahoo Finance: Shopify partners with Meta Muse for AI-powered checkout (22 September 2026)](https://finance.yahoo.com/technology/ai/articles/shopify-partners-meta-muse-ai-115807895.html)
- [The Paypers: PayPal partners with Meta on Muse checkout (24 September 2026)](https://thepaypers.com/payments/news/paypal-partners-with-meta-to-bring-checkout-to-muse-ai-agent)
- [Fortune: Amazon blocks Meta's Muse (22 September 2026)](https://fortune.com/2026/09/22/metas-muse-ai-is-exploding-in-popularity-and-drawing-heated-backlash/)
- [Model Context Protocol specification, 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)
- [The MCP Registry: about, trust and security](https://modelcontextprotocol.io/registry/about)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt