Muse connectors: a new MCP growth channel
Muse connectors let Meta’s personal AI agent use your product while it works on a user’s task. If your team ships an MCP server, Meta’s new Muse Connector Platform gives it one more place to be found: a reviewed catalog that the Muse agent itself can search when a user asks for help. This article explains what the platform is, why I see it as a new MCP distribution channel, what Meta expects from a connector, and how to test your server before you submit and measure what the listing brings once it is live.
Key takeaways
- The Muse Connector Platform is Meta’s program for listing integrations in Muse. Its terms count MCP servers as connectors.
- Approved connectors can be found by the Muse agent and in Settings > Connectors, and Meta’s editors pick some for featured placement.
- Meta asks connectors to finish the tasks they start and to do more than Muse can already do in a browser. A wrapper around public pages is not enough.
- Review covers risk, every tool and end-to-end testing. In my view, prompt injection is a big part of why every AI connector directory reviews this strictly.
- Test OAuth and validate your tool descriptions in MCP Tower before you submit, then use it to see which agents call your server once you are listed.
This article is the long version of lesson 1, What is MCP? A primer on the channel after search, of Growing Your MCP Server: A Crash Course, a free course on getting an MCP server listed, measured and used.
What are Muse connectors?
Muse is Meta’s assistant, described on the platform’s home page as “the personal AI agent that gets things done”. A connector, in Meta’s words, “brings what you’ve built into the everyday tasks people ask Muse to help with”. The Connector Platform Terms define the term broadly: connectors, actions, plug-ins, MCP servers or other integrations that work with Muse. The terms took effect on September 18, 2026, so the program is new.
Claude and Muse call these integrations “connectors”. ChatGPT and Grok call theirs “plugins”. The idea is the same in each case: a remote MCP server (Model Context Protocol), reviewed and listed, that the assistant calls on the user’s behalf.
Users meet connectors in two places, per Meta’s Help Center. They can open Settings, then Connectors, and tap Connect. Or they can just ask Muse, for example “Connect my Gmail”. Users can also add a custom connector that Meta does not review, but the reviewed catalog is where your listing lives.
Why the Muse Connector Platform is an MCP distribution channel
Most software reaches people through search, ads and word of mouth. A listed connector can also reach them through the assistant, at the moment they ask for something your product does. Three points in Meta’s connector guidelines make this a channel worth planning for:
- The agent can find you. Approved connectors “are discoverable by the Muse agent” as well as in Settings, so a user who has never heard of you can still reach you through a task.
- Featured placement exists. Featuring is an editorial decision based on usefulness, task completion, reliability and maintenance. Meta is clear that meeting the guidelines does not guarantee featuring, ranking or traffic, but the criteria are things you control.
- Payments are part of the plan. The platform’s home page says Meta has partnered with Stripe so connectors can accept payments with Link. Connectors that book, buy or renew things fit the program as well as those that read data.
That is what made app stores a growth channel for mobile apps: a catalog inside a product people already use, with an editorial shelf on top. The Muse catalog is at an earlier stage, and I think that is when a well-built listing stands out most. Meta does not publish user numbers for Muse, so treat the size of the opportunity as unknown until you see your own traffic.
What Meta expects from a Muse connector
The guidelines are short and specific, and two requirements set Muse apart from the other AI connector directories.
Finish the task
Muse should be able to complete every task your connector starts, within its approved tools. For a booking service that means search, full price, authorization, checkout, confirmation and follow-up. The docs say it plainly: sending the user off to finish the whole checkout “does not meet the completion requirement”. Their worked example, a fictional hotel service called Cedar Stays, shows the full total with taxes and fees before approval and reports a booking as confirmed only once the provider confirms the reservation and payment.
Do more than the browser can
Muse can already browse the web. A connector has to add value beyond that, through better information, account access, more reliable actions or fewer steps. “A wrapper around public pages or a list of links alone is not enough.” If your MCP server mostly returns what your public site already shows, that is the first thing to fix.
Classify every tool honestly
Meta sorts tools into Read, Write and Sensitive write. Users choose Allow once, Always allow or Deny for each one, and a sensitive write, such as a payment, asks every time and can never be set to Always allow, per the scope of approval rules. The guidelines forbid hiding a send, share, publish or payment action inside a tool described as a read or a routine edit.
The trust and integrity section adds the rest: collect only the data each tool needs, never sell it or use it to train models, describe prices and outcomes accurately, and report a security incident involving user data within 48 hours. Finance connectors get read access only for now.
Muse vs Claude and ChatGPT
Each assistant asks for something different, and the difference hints at how it plans to match connectors to requests.
ChatGPT asks for positive and negative test cases, prompts your app should and should not handle. I cover that in why the ChatGPT plugin directory can be a growth channel. Claude asks for use cases and example prompts and can suggest a connector in the middle of a chat, as I describe in why the Claude Marketplace can be a new growth channel.
Muse asks a different question: can the agent finish the job, and is it safe to let it? The submission wants a connector overview that explains how you improve on browser use, plus tool documentation with Read and Write labels, sensitive actions, side effects, errors and rate limits. The emphasis is on completed actions and on permissions, which fits an agent meant to book, buy and send things for people.
I look at two more assistants in my pieces on Perplexity connectors and Gemini connected apps.
Why the review is strict, and how to pass it the first time
Meta reviews each submission in three stages: a risk assessment of security, privacy and integrity, a review of every tool’s classification, and end-to-end QA that includes manual testing. Only tools that pass are approved, and approval of the connector does not cover the others.
In my view, prompt injection is the main reason AI connector directories review this carefully. A tool’s name and description go straight into the model’s context. A description that tells the agent to call other tools, fetch instructions from elsewhere or favor a product can steer every conversation where the connector is active. For an agent that can make payments, the stakes are higher still.
Fix what a reviewer would flag before they see it. When you add your server to MCP Tower, its Inspect module validates every tool and its description and gives you recommendations. You can fix them on your server, or change a tool’s title and description right in Inspect with an override, without waiting for a developer or a deploy. Going through the list is also a good moment to decide which tools are Read, Write or Sensitive write before you fill in the form.
Test sign-in too. Broken authentication delays review, because a reviewer who cannot connect with
your test account cannot run a single tool. MCP Tower runs your OAuth flow as a set of checks,
from the 401 challenge and discovery documents to token exchange and refresh, and reports where it
broke and what to change.
For the full steps, see how to submit a connector to Muse.
How to make your connector the one Muse picks
You cannot buy placement. You can make your server an easy match for the agent and an easy yes for the editors:
- Describe the task a user completes. “Book a room for two nights near the conference venue” matches a request. “Hospitality platform” does not.
- Keep one job per tool. Narrow tools are easier to classify, approve and choose. Keep payments in their own tools: a sensitive write asks every time, while other tools can be set to Always allow.
- Return the full picture before commitment. Seller, full price, recurring charges, key terms and the refund policy, as the transactions rules require.
- Handle failure without duplicates. Check the original action’s status before any retry, and say clearly whether something is quoted, pending, confirmed, failed or cancelled.
- Offer read-only access. Where you sign users in with OAuth, Meta asks for a Read Only option when possible. In my view it also makes a user more likely to connect at all.
Measure what the Muse listing brings you
SEO specialists rely on tools that show which queries bring visitors, which pages convert and what breaks. They change a page, then check again. A Muse listing deserves the same loop, and Meta’s docs do not describe any usage dashboard for connector developers.
The MCP Tower setup you used to test before submission keeps working after approval. It sits in front of your server as a proxy: you point a hostname you own at it with a DNS change, so the URL you publish can stay the same, and every request is recorded on the way through, with no SDK or code change on your server. That gives you:
- Every agent in one place. Each call carries the agent it came from and how far that label can be trusted. Muse does not identify itself in a way MCP Tower can verify, so MCP Tower infers Muse traffic from Meta’s network and marks that label as inferred.
- Per-tool usage and reliability. Which tools get called, how often, how fast and with which errors, filtered by agent, country and date. Reliability is one of the featuring criteria, so this is the number to watch.
- What happens after the call. Users and sessions, widget interactions, and clicks on the links your tools return.
- Uptime from outside. Scheduled checks list your tools through MCP Tower and record latency and errors, even when nobody is using the server.
Because the URL you submit is the one you keep, set up MCP Tower before you submit. Then the first day of traffic is already measured. See pricing for plans.
Conclusion
Muse connectors put your MCP server inside an agent built to complete tasks, with a catalog the agent can search and an editorial shelf for the best entries. Meta wants connectors that complete the task and say plainly what each action does. The teams that do well will test sign-in and tool descriptions before they submit, then watch what agents and users do once the listing is live.
Get started with MCP Tower to test your MCP server before you submit to Muse, then see which AI agents use it from the first call.
