How to Get Your App on Muse: Connector Submission Guide

Last reviewed 19 September 2026. Every claim below is backed by a source in Sources. Where we have no source, the guide says so.

Meta opened third-party connector submissions at muse.ai/platform on 19 September 2026. There were no developer docs on the day it opened, so this page is the walkthrough we wrote for ourselves while submitting two products of our own: AppStoreCopilot and ClipSubtitles.

What this guide covers, and what it can't

It covers the intake: the three steps of the submission form, every field we were asked for, the limits the form enforces, and the wording of the attestations you have to agree to.

It cannot tell you what happens next. We submitted both of our products on 19 September 2026 and neither has a decision. Anyone telling you the review time, the approval rate or the criteria is guessing — there is no published figure, and we have not seen one either. When that changes we will update this page and change the "last reviewed" date at the top.

One more limit worth stating: the connector directory itself lives inside the Muse app, behind sign-in, and Muse's robots.txt prohibits collecting data from the site by automated means. So there is no public page that will tell you whether a submission went live. You find out by looking in the app.

What to have ready before you open the form

The form is short, but it will not let you save your way around a missing asset. Have all of this in hand:

• A live endpoint. Either a hosted MCP endpoint over HTTPS, or an API URL (optionally with an OpenAPI URL). You pick which on step 2.
• An HTTPS product website.
• A privacy policy URL and a terms URL, both reachable without signing in.
• A support email address or support URL.
• One icon file: PNG or SVG, 512 by 512, 256 KiB or smaller.
• A company email address. The form asks for a work email and says to use your company one.
• Example prompts — free text, so this is your one chance in the Overview step to show what the connector is actually for.
• A decision on payments: whether your connector takes payment inside Muse.

Signing in creates a Meta account

This surprised us, so it is worth flagging early: signing in to submit is not a lightweight developer-portal login. It creates a Meta account.

What we saw, in order:

1. You enter the work email address.
2. A six-digit code arrives from security@account.meta.com, with the subject "Confirm your email address for your new Meta account".
3. The next screen asks for a date of birth and shows the line: "By tapping Confirm, you'll create an account and agree to these terms… Your AI interactions may be used to improve AI at Meta."

Two practical consequences. First, decide whose account this is before you start — it is a real Meta account with a real date of birth attached, and those consumer terms apply to it. Second, the date-of-birth selectors default to today's date, so do not click through that screen on autopilot.

Step 1 — Overview

The form has three steps — Overview, Technical specs, Review — and the Overview step is the longest. These are the fields and the limits we hit:

| Field | Notes | | --- | --- | | Connector name | 80 characters or fewer | | Company / developer | 120 characters or fewer | | Product website | Must be HTTPS | | Example prompts | Free text | | Icon | Exactly one file, PNG or SVG, 512 by 512, 256 KiB or smaller | | Payments | A select: accepts payments, or does not accept payments | | Your name | The person submitting | | Work email | The form says to use your company email | | Support | An email address or a support URL | | Privacy URL | Required | | Terms URL | Required | | Notes | Optional, free text |

Two of these deserve more than a row.

The icon check reads the file, not the filename. A PNG whose header does not declare exactly 512 by 512, or whose bytes do not match the extension you gave it, is rejected. If you exported an icon from a design tool and renamed it, check the actual dimensions and the actual format before you upload it rather than trusting the filename.

The payments question is narrower than it looks. It is asking whether money changes hands inside Muse. A SaaS product that bills customers on its own site and merely authenticates them in Muse is not accepting payments in Muse, and answers that it does not.

Step 2 — Technical specs

Step 2 asks how Muse should reach your product. The choice is between two connection types:

• Existing MCP — a hosted MCP endpoint, over HTTPS.
• Raw API — an API URL, plus an optional OpenAPI URL.

Alongside that:

• Docs URL.
• Access requirements — what a user needs to use your connector: an account, a particular plan, a region, rate limits.
• Auth methods (optional, with a free-text description): API keys, OAuth with PKCE, or Other.

If you already run an MCP server for another assistant, this is the step where that work pays off: the endpoint you already host is the one you paste in.

Step 3 — Review and attestations

The last step is three required checkboxes, then Submit for review. The wording, exactly as the form puts it:

I confirm I'm authorized to submit this connector and its brand assets.

I understand that submission doesn't guarantee approval and promotion is based on usage and editorial discretion.

I agree to the Muse Connector Terms.

Two notes. The first checkbox is about brand assets as well as the connector, so whoever ticks it needs to actually hold the rights to the icon you uploaded — if someone else designed it, settle that first.

The third links to the Muse Connector Terms. When we looked at that page while signed out it returned "content isn't available", so you may only be able to read the terms you are agreeing to from inside a signed-in session. Read them there before ticking, rather than after.

What the form does not ask for

If you have submitted to other assistant directories, the absences are the interesting part. The Muse form did not ask us for:

• screenshots
• written test cases
• reviewer credentials
• a demo video
• a domain-ownership challenge
• a security scan of the endpoint

What muse.ai/platform says instead is that Meta runs its own functional, security and legal review, including end-to-end testing.

That inverts where your effort should go. There is no reviewer packet to write and no test script that will steer what gets tried. The live endpoint is the submission. Whatever a tester does against it on an ordinary day is the thing being judged, so freeze the deployment you submitted and stop shipping changes to it until you hear back — otherwise you will be judged on behaviour you never tested.

If your product is gated and a reviewer genuinely cannot get in, the notes field is the place to offer a private reviewer account and a way to request it. Do not paste credentials into the form.

Five things worth getting right first

These come from building the two connectors, not from the form.

1. Reviewer access has to outlast the review. If your product is behind a paywall, a reviewer account with a one-month allowance will expire mid-review and you will not be told. Give the reviewer path a longer window than you think you need, and a way to renew it without a code change.
2. Know what your server does with a browser Origin header. Our MCP server allows requests that carry no Origin and returns 403 for unrecognised browser origins, and that check runs after authentication — which means an unauthenticated probe returns 401 and tells you nothing about whether the origin check would have passed. Find out how yours behaves before you submit. We have not seen a live origin rejection from Muse, so do not pre-emptively add an allowlist entry for it; wait until you have a real failure to fix.
3. Muse's OAuth callbacks. The callback routes we saw were muse.ai/connect/oauth-callback and muse.ai/connect/ac-oauth-callback. If your authorization server supports dynamic client registration, there is nothing to allowlist. If your provider needs a statically registered client instead, that is a production change on your side — find out which case you are in before submission day, not during it.
4. A tool that needs prior state will fail. Assume every tool call happens in a fresh conversation with nothing attached and no earlier turn to refer back to. If a tool only works after another tool ran, or only if the user already uploaded something, it will be tried cold and it will fail. This is the single thing we have seen sink a submission on another directory.
5. Your example prompts are the brief. They are free text and they are the only place you get to say what good use of your connector looks like. Write prompts a stranger could paste in and get a useful result from, first try.

What we still don't know

Listed plainly, because a guide that hides its gaps is worse than a short one:

• How long review takes, and what the decision looks like when it arrives.
• Whether there is an appeal or resubmission path after a rejection.
• Whether approved connectors get any listing controls afterwards — a description, categories, an update mechanism.
• Whether OAuth with PKCE is preferred over API keys in practice, or merely offered.
• What, if anything, the directory looks like from the inside once you are in it.

We have two submissions pending, so we will know some of this before most people do. This page gets updated when we do, not before.

Built a connector and want it listed here? Send it to us with a source.