Muse takes connectors now.

What Meta has said

The announcement was Mark Zuckerberg's, on 18 September: "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. People reach your service just by asking for it, and their agent takes it from there. New connectors are live today." The clip under it shows connector logos orbiting the Muse mascot, which is the whole model in one picture: the agent in the middle, your service one of the things it can reach.

The programme page is short. "Meet your users where they are with Muse Connector Platform." A connector "brings what you've built into the everyday tasks people ask Muse to help with", and Meta has "partnered with Stripe to make accepting payments easy with Link". Then the three steps: describe your product, submit for review, appear in the directory. The review covers "functional, security, and legal requirements" and includes "end to end testing". Once approved, "editors will review connectors for featured placement".

That is the whole of the public documentation as of today. No developer docs, no pricing, no revenue share, no stated review time, and the Muse Connector Terms link on the final step returns a page that says the content is not available. Everything below comes from the form itself.

The form, field by field

The Submit a connector button responds only to a real click; as a link it points back at the same page. Clicking it opens "Submit your connector for review" and asks you to sign in or create an account with a work email. A six-digit code arrives by email. A new account is asked for a date of birth and created on Confirm, which also accepts Meta's terms.

Step 1, Overview. Connector name. Company or developer. Product website. Example prompts, with the placeholder "What might someone ask Muse to do?" and examples about training plans and dining-room lights. A connector icon, 512 by 512, PNG or SVG. Payments: accepts payments, or does not. Your name. Work email, with a note to use your company address. Support email or URL. Privacy policy URL. Terms of service URL. An optional "anything else" box.

Step 2, Technical specs. Connection type, a two-way switch between Raw API and Existing MCP. For a raw API: the API URL, an optional OpenAPI specification URL, documentation. For MCP: a hosted MCP endpoint and documentation. Then access requirements, described as "anything that affects who can use the connector or what it can do", and authentication methods as three checkboxes: API keys, OAuth with PKCE, Other.

Step 3, Review. Everything read back, two Edit links, and three confirmations: that you are authorised to submit the connector and its brand assets, that submission does not guarantee approval and promotion is based on usage and editorial discretion, and that you agree to the Muse Connector Terms. Then Submit for review, and a thank-you screen that says Meta will review and get in touch.

What a connector is

The useful fact in the form is the connection type. Meta is not asking for a manifest, an SDK integration or an uploaded package. A connector is a live endpoint Meta can test against: a remote MCP server with OAuth or API-key authentication, or a plain API with a spec. That is the same shape as the Claude connectors directory and the ChatGPT app path, and it means one MCP server can be filed with all three without changes.

It also means the review is against behaviour, not paperwork. "End to end testing" implies someone at Meta connects to the endpoint, authorises, and runs the tools the way a Muse user would. The access-requirements box is where you tell them what will get in their way: account creation, plan limits, rate limits, regional restrictions.

What we filed

• Connection type: Existing MCP, hosted endpoint https://api.stacktr.ee/mcp, documentation at stacktr.ee/docs.
• Authentication: API keys and OAuth with PKCE. Discovery is at /.well-known/oauth-authorization-server and dynamic client registration is on, so a client that has never seen the server can register itself.
• Payments: none. Stacktree bills outside the assistant and never links to checkout from a tool result.
• Example prompts: "Publish this report as a private link I can send to Ana." "Put a passcode on that page and give me a link for the client." "Update the page with the new numbers, same link." "Has anyone opened the proposal I sent on Tuesday?"
• Access requirements: an account created during the OAuth flow, the free plan's limits, what paid plans add, no regional limits, and how rate limits and plan walls come back to an agent (429 with Retry-After, 402 with a machine-readable reason).

What changes for you

Today, nothing you have to do. Muse can already publish to Stacktree because it runs a full browser on its own VM and Stacktree's first publish needs no account: one request, a private link back. That is how the Muse page has read since launch day, and it still holds.

If the connector is approved, the path gets shorter and wider. Shorter, because Muse calls publish_html directly instead of driving a browser through our instructions. Wider, because the connector is bound to your Stacktree account, so the tools that need one become available in the conversation: passcodes and email-domain gates, a share link per recipient with read receipts, client spaces on your own domain, version history, and updating a page in place at the link you already sent. And because Stacktree pages can now answer questions about themselves, the person you send the link to gets an answer from the page, not from a chat they are not in.

We will update the Muse page the day Meta writes back, either way.

What we could not find out

Review time. Whether the directory needs a verified business, as OpenAI's did. Whether the account has to be the one the listing appears under, or a company identity can be attached later. What the Muse Connector Terms say, because the page would not load. If you have been through the review and know any of these, tell us and we will add it here with credit.