How to get your app into Meta Muse and Grok with one MCP server

xAI opened Grok to outside apps on May 6, 2026. Meta launched Muse on September 8 and has since opened a connector directory with its own review. Two of the largest consumer agents now take requests like “reorder last month’s supplies” and hand them to someone else’s software. Whether that software is yours depends on one thing: a server the agent can call.

For both agents, that server is the same. A remote MCP server covers Grok today and Muse’s custom connectors, and it works in Claude and Cursor too. This guide covers what each agent accepts, what the server needs, and when you can skip it.

What does it take to get your app into Muse and Grok?

You need a remote MCP server: a public HTTPS endpoint that exposes your app’s actions as tools, signs users in with OAuth and enforces what each user may do. Grok connects to any such server as a custom connector. Muse users can add one as a custom connector, and Meta reviews connectors for its public directory.

MCP, the Model Context Protocol, is the open standard both hosts use to discover and call tools. Your server lists its tools, such as search_orders or create_invoice, with a description and an input schema. The agent reads that list, picks a tool for the user’s request and calls it with the user’s token. Your server decides whether the call is allowed.

It is the same work our AI agent development team does when an agent has to act inside a client’s own systems. Here the agent just belongs to Meta or xAI.

How Muse and Grok connect to outside apps

Each agent has a curated route and an open route, and the open routes are where an MCP server goes. The table uses each vendor’s own pages, checked October 12, 2026. Both products change month to month.

Two details matter for planning. Muse runs each user’s agent on a dedicated cloud machine, so it calls your server from Meta’s cloud, never from the user’s laptop: a server on a private network or localhost will not work. And Muse’s custom connector flow is documented mostly by third-party developers so far, so test it yourself before you promise it to customers.

Why an MCP server and not just your API or website

Agents can reach your app without your help: Muse can drive a browser, and developer guides show it writing its own integration against a public API. An MCP server is how you decide what the agent can do instead of leaving it to guesswork.

• Browser use breaks when your screens change, can’t tell a read from a write and leaves no clear audit trail of what the agent did.
• A raw API exposes every endpoint in the shape your frontend needed, which is rarely the shape an agent should call. A 40-parameter endpoint invites wrong calls.
• An MCP server exposes a short list of named tools with plain descriptions, behind your own sign-in and scopes. Every host that speaks MCP can use the same server, so you build it once.

The last point is the business case. Muse and Grok are two hosts; Claude and Cursor also connect to remote MCP servers, which is how Relm’s customers use it. One well-built server works in all of them.

What a production MCP server needs

The MCP specification defines how authorization works, and most of the requirements land on your server. The checklist below follows the specification’s Authorization page and its Security Best Practices page (version 2025-11-25).

• Public HTTPS endpoint. Both hosts call from their cloud. All OAuth endpoints must be served over HTTPS.
• OAuth 2.1, with your server as the resource server. The server publishes Protected Resource Metadata (RFC 9728) so the agent can find your authorization server, either at a well-known URL or in the 401 it returns to calls without a token.
• Tokens issued for your server only. The specification requires the server to check that each token was issued for it, and forbids passing a client’s token through to another API. If your MCP server calls your own backend, it uses a separate token.
• Small scopes, raised on demand. Start with read-only scopes and ask for write scopes the first time a write tool is called (a 403 with insufficient_scope). Broad scopes such as * or admin are the specification’s own example of a mistake.
• Separate read and write tools. get_invoice and void_invoice should never be one tool with a flag.
• A confirmation step on high-impact actions. Muse checks with the user before sensitive actions such as sending email or buying something. Don’t rely on that. Make the server return a preview and require a second, explicit call to commit anything that moves money, deletes data or contacts a third party.
• Per-user limits and an audit log. Rate limits per token, and a log of every tool call with the user, the arguments and the result. When a customer asks what the agent did, you need the answer.
• Secure session handling. Session IDs must be random and must not stand in for authentication; every request is checked.

None of this is exotic. It is the same discipline as a public API, with one difference: the caller is a model that can be talked into things, so the server has to say no on its own.

How to design tools an agent uses correctly

Design tools around the jobs users ask for, not around your endpoints. An agent picks a tool by reading its name and description, so “reorder_from_previous_order: creates a draft order with the same items as a past order; does not charge” beats a generic post_orders.

Rules we apply to tool design:

• One job per tool, named with a verb and an object.
• Descriptions that state what the tool does not do, such as “does not send” or “draft only”.
• Few, typed parameters with enums wherever the values are known.
• Idempotent writes, with a client-supplied key, so a retried call doesn’t place two orders.
• Short, structured results with IDs the agent can pass to the next tool, not full records.
• Errors the agent can act on, such as “address missing: ask the user for a delivery address”.

Treat everything that comes back from the agent as untrusted input. A prompt injected into an email or a web page can make an agent call your tools with arguments the user never intended. Server-side checks, scopes and confirmations are what stop that, not the agent’s judgment.

What we built for Relm

Relm is a commercial real estate platform we built, and it ships a production MCP server. It exposes 44 tools over both REST and MCP, so firms can point Claude, Cursor or their own agents at Relm’s research and underwriting instead of logging in to the web app.

The parts that carried over from the web app were the hard ones: tenant isolation across the database, vector store and AI context, and an audit trail. The MCP layer reused them instead of adding a second set of rules. That is the pattern we recommend: the server is a thin, well-described layer on top of permissions you already enforce. The Relm case study has the full scope.

Relm is not listed in Muse or Grok, and we have not measured how either agent uses its tools. What the case shows is the server side: the same remote MCP server serves several agent hosts without changes.

What an MCP server costs and how long it takes

For an app that already has a clean, documented API, the MCP server is a small build. Most of the effort goes on OAuth, tool design, confirmations and testing in each host, not on the protocol. We price it like any other project: a Fixed-Price Build inside our $25k–$120k band, with the scope and price fixed after a two-week Discovery Sprint. For a server on top of an existing API, we expect the low end of that band, and that placement is our judgment, not a quote.

What moves the price:

• No usable API. If the app’s logic lives in its frontend or in scripts, the API comes first, and that is the bigger project.
• Write actions that move money or reach customers, which need previews, confirmations and stronger tests.
• Multi-tenant data, where tenant isolation has to hold for every tool.
• Directory submissions, which add review cycles on Meta’s timeline, not yours.

Running costs are hosting and monitoring for one more service. The agent runs on Meta’s or xAI’s infrastructure, so its model usage is not on your bill. See pricing for the full engagement model, and AI agent development cost if the agent itself is yours to build.

When you don’t need an MCP server yet

Skip it for now if your customers don’t use these agents for the job your app does. A connector nobody calls is maintenance with no return.

It also isn’t the right first step when:

• Your app has no API. Fix that first; every integration, agent or not, will need it.
• A connector already exists, for example through an integration platform your customers use, and it covers the jobs they ask for.
• Your product is mostly reading, such as public prices or documentation. Agents can already read a fast, well-structured website; a server adds little.
• You need the directory listing specifically. Meta has not published a timeline or fee for directory review. Build the server for custom connectors and other hosts first; the directory is a second step.

If several of these apply, wait. If customers already paste data from your app into ChatGPT or Grok to get work done, that is the signal to build.

How to decide this week

Answer these for your own app, in writing:

• Which three jobs would a customer ask an agent to do in your app?
• Does an API already cover those jobs, with per-user permissions?
• Which of those jobs write data, move money or contact someone?
• Who owns the server after launch, including changes when Muse or Grok change their rules?
• Which hosts matter to your customers: Muse, Grok, Claude, ChatGPT or Cursor?

If the first two answers are clear, the server is a short project. If they aren’t, the work starts with the API, and a build vs buy decision for AI agents is the better place to start.