How to Get Your App Listed as a Muse Connector (The Practical Path)

On September 18, 2026, ten days after launching Muse, Mark Zuckerberg posted the sentence that turned a product into a platform: “Opening access for developers to build Muse connectors. You bring the API. Muse brings the agent, the browser, and the context of what the person actually wants.”

Within a week, more than 1,500 developers had applied, according to Meta AI chief Alexandr Wang. Commerce partnerships followed: Shopify, PayPal, Instacart, Expedia. The connector directory at muse.ai/platform is where the next wave of distribution is being decided.

Here is the practical path from having an API to being listed, based on how the platform actually works as of September 2026.

The three ways Muse connects to services

Before you build anything, understand which path your product takes:

Built-in connectors are partnerships Meta arranges directly: Gmail, Spotify, Ticketmaster, OpenTable, Plaid at launch. You cannot apply your way into this tier.

Custom connectors are the path for everyone else. Muse builds the integration itself on its own cloud VM: you hand it your API docs or MCP server URL, it writes the client code, stores credentials in its Secure Credentials Store, and saves a reusable skill. Meta does not review these. Any Muse user can already connect to your API today with no listing and no permission from Meta.

The browser is the fallback for sites with no API. Muse drives Chromium directly. It works, and it is the most fragile and most token-expensive option.

The directory listing, then, is distribution and trust, not a technical prerequisite. That distinction shapes everything below.

The submission flow

Meta’s platform page lays out three steps:

1. Describe your product. What your connector does and the everyday task it completes. This is positioning: “ask Muse to book a table” beats a feature list.
2. Submit for review. Meta checks functional, security, and legal requirements and runs end-to-end testing.
3. Appear in the directory. Approved connectors become findable inside Muse, and editors review for featured placement, which is the real prize.

There is no listing fee and no revenue share right now. Meta partnered with Stripe to handle payments through Link, which tells you what the platform wants: connectors that complete transactions, not ones that fetch information.

What reviewers actually check

There is no published rubric, but submitter reports and Meta’s own documentation converge on a checklist:

• A live product on a custom domain with valid HTTPS. Not localhost, not staging.
• A landing page that explains the product in one screen.
• A privacy policy and terms of service at public URLs, written for your actual data practices.
• A support contact you actually monitor.
• Documentation a reviewer can follow without an account, up to the auth step.
• Token-based auth (Bearer or API key) with self-serve key issuance.
• Test credentials for the reviewer, clearly labeled.
• A demo of the connector working through Muse.

Anything the reviewer cannot complete alone is a rejection. Test your flow as a stranger before you submit.

The fastest technical path: a hosted MCP server

Of the three build paths, a hosted MCP server over streamable HTTP is the shortest. Muse already speaks the Model Context Protocol natively, and a remote server is reachable from its cloud VM like any other client.

The design rules that matter:

• One tool, one job. A tool that does five things gets called for the wrong reasons.
• Names are verbs. cancel_subscription beats subscription_manager.
• Descriptions are load-bearing. Muse decides when to call a tool from its description alone. Write documentation, not marketing.
• Structured errors. Every failure returns a code, a message, and a hint about what to do next. A stack trace is a bug in your server.
• Return data, not prose. JSON the agent can act on, including IDs for follow-up calls.

If you already have a REST API, you may not need MCP at all: publish an OpenAPI 3.x document at a stable public URL and Muse can build the custom connector against it. Audit your docs by handing them to any AI agent and watching where it stumbles. Every stumble is a rejection risk.

The one-afternoon plan

This is the sequence that works:

1. Deploy. Get a public HTTPS URL for your MCP server or API. Confirm a health check responds.
2. Define tools. Three perfect tools beat ten vague ones. Write the descriptions first.
3. Build. Ask Muse to connect, test every action end to end, and save the integration as a skill. Fix friction in your server, not in the chat.
4. Harden. Have Muse call every tool with missing parameters, invalid values, and an expired credential. Every failure must return a structured error.
5. Regression. From a fresh conversation, re-run everything using only the saved skill. Zero improvisation allowed. If Muse has to guess, a reviewer will too.
6. Submit. Checklist complete, demo recorded, test credentials labeled, submit at muse.ai/platform.

The honest risks

Platform risk is real. Amazon blocked Muse from shopping on Amazon.com within days of the connector announcement. Services with their own distribution will fight the agent layer. Build for the platform, not only for it.

Review is a black box. No published rubric, no described appeals process.

The directory is getting crowded. 1,500 applications in week one. Early listing is an advantage, not a moat. Your moat is the product.

Skip the three weeks

We packaged this entire path into the Muse Connector Kit: the 16-page playbook covering everything above in depth, a production-ready MCP server template in Python (tested, with auth, structured errors, and a Dockerfile), a worked example walked through hour by hour, five copy-paste prompts for building and hardening your integration, and the pre-submission checklist. $79, with lifetime updates as the platform evolves.

The shelf is free right now. It will not stay that way.