Meta opened Muse to outside connectors on September 18, 2026, but it did not publish an SDK, a spec or much of a how-to. What exists is a three-step page at muse.ai/platform and a review process. This guide pulls together what is known about getting a connector listed, using the most complete public example so far: the listing pack tickadoo published on GitHub. Meta can change any of this, so check muse.ai/platform for the current form before you submit.
What Meta counts as a connector
A Muse connector is a live service Meta can test against: a remote MCP server with OAuth or API-key sign-in, or a plain web API with a published spec. Nothing is uploaded. Meta's reviewers point Muse at your public endpoint and test it end to end. If you already run a remote MCP server for Claude or ChatGPT, you can file the same server with Muse without changing it.
The three steps
- Describe your product. What it does, who it is for and what people will ask Muse to do with it.
- Submit for review. Meta checks functional, security and legal requirements and tests the connector end to end against your live server.
- Appear in the directory. Approved connectors show up in Muse's own connector list, and Meta says its editors pick some for featured placement.
The form asks you to sign in with a work email address. A personal email, or an AI agent filling the form for you, will not get past that step, so a person at your company has to do the submitting.
The pattern that works: a listing pack
With no SDK, builders have settled on a simple shape: publish a written brief for your connector, point Muse at a public HTTPS or MCP server, declare exactly which web addresses it is allowed to call, and keep every password and key out of the repository. tickadoo, a ticket-booking platform, published the cleanest example. It is six short files, each written for a different reader:
| File | Who reads it | What goes in it |
|---|---|---|
| Brief | Muse itself, and reviewers | What the service does, the endpoint, sign-in, allowed hosts, rate limits and the rules Muse must follow |
| Skill file | Muse | A short summary with the allowed hosts listed at the top, plus the hard rules |
| Install prompt | Users | Text to paste into Muse that builds the connector as a custom connector, with no approval needed |
| Submission | Meta's reviewers | The answers for Meta's form: name, description, example requests, category, technical details, data handling and payments |
| Security note | Meta's security and legal review | The trust boundary, what data you receive, what you never receive and where payment happens |
| Evals | Meta's testers, and you | Copy-paste test commands and plain-language test requests, each with what a pass looks like |
The brief lives at one stable public URL, so the install prompt, the skill file and the reviewers all read the same source of truth. See tickadoo's pack on GitHub.
What to put in the submission
Expect to cover a one-line description, how people will use it, a category, the technical integration, authentication and data, and payments if money is involved. Write example requests in the words a normal person would use, such as "Get two tickets for The Lion King this Saturday", and describe the steps Muse should follow for each one. Say plainly what data your service receives and what it never receives. If something is bought, say where checkout happens. tickadoo hands Muse a booking link and keeps payment on its own site, which is the simplest position to defend in a review.
Make sure Muse can actually reach you
Muse runs connectors from a cloud computer, and its network path is stricter than an ordinary browser. tickadoo's notes describe connection attempts timing out from inside Muse even though their server answered in a fraction of a second everywhere else. Their fixes are worth copying: return a single JSON response instead of relying on a long-lived streaming connection, accept plain HTTP/1.1, keep the first handshake fast, and make a simple GET to your MCP address return a clear answer (a 405 is fine) so an agent can tell the server is up. Test from outside your own network before you submit.
Write tests reviewers can run
A short evals file does two jobs. It shows reviewers exactly how to check your connector, and it tells you before Meta does when a change breaks something. Include the handshake, one search a reviewer will recognize, one live check such as availability or details, and a handful of user requests with clear pass and fail rules, such as "does not invent a time that is not on sale" or "never asks for a card number in the chat".
While you wait for approval
Review is not quick. As of early October 2026, submissions we know about were still showing "Submitted" weeks after they went in, and Meta has not published a timeline. You do not have to wait to be useful. Anyone can add your server to Muse today as a custom connector, which is exactly what tickadoo's install prompt does. Meta does not review custom connectors, so people are trusting you directly, and a clear security note helps them decide.
You can also list your connector on musedirectory.ai for free. We check it every 15 minutes, give you a live status badge for your site, and show it to Muse, ChatGPT and Claude users, because the same remote server works in all three.
Checklist before you submit
- A public HTTPS or MCP endpoint that answers fast from outside your network
- Sign-in that works without a laptop or local process (OAuth, an API key, or none for public data)
- A written brief at a stable public URL
- A list of every host the connector may call
- Five or more example requests in plain language
- A short security note: what data you get, what you never get, where payment happens
- Test commands with pass and fail rules
- A work email address to sign in to the submission form
- An install prompt so people can use it as a custom connector while you wait