Grok Bot Bring Your Own MCP: Giving Grok Governed Access to Any API

Most of what is written about Grok's connectors covers the seven built-in ones. The more interesting line in xAI's announcement is the eighth option: Bring Your Own MCP, which lets you point Grok at a custom MCP server and have it discover whatever tools that server exposes.

That is a general-purpose door into Grok. It is also the only route that gives you control over what Grok may actually do, because with a custom server the allow list is yours rather than the vendor's.

There is one requirement that shapes everything else, and xAI states it plainly.

How to add one

From xAI's documentation, the flow is three steps:

1. Go to grok.com/connectors
2. Click New Connector, then select Custom
3. "Enter the MCP server URL and complete any required authentication"

After that, Grok discovers the tools the server exposes and can use them in conversation the same way it uses built-in connectors.

On Business and Enterprise plans, a team admin must provision the connector in the cloud console before members can use it.

The requirement that shapes the design

Here is the line that matters: "Your MCP server must be reachable over the public internet."

If your server runs on a local machine, xAI's docs direct you to a tunnelling service, and they maintain a separate page about it. This is not an incidental detail. It is the difference between adding an MCP server to Cursor and adding one to Grok.

Cursor, Claude Code and Windsurf start a local process and talk to it over stdio. Nothing is exposed. Grok is a hosted product, so your server has to be somewhere Grok's infrastructure can reach, which means a public address, which means you are now running an internet-facing service that can execute API calls on your behalf.

That is a perfectly reasonable thing to do. It is not a thing to do casually.

What this means for Swytchcode specifically

Being straight about this, because the naive version of this post would skip it.

Swytchcode's MCP server runs over stdio by default, which is ideal for an editor and useless to Grok. It also has an HTTP transport:

swy mcp serve --transport http --port 5476

That serves at http://127.0.0.1:5476/sse and is localhost-only. It binds to the loopback interface deliberately. So connecting Grok to it is not a matter of flipping a flag; it means putting a tunnel or a reverse proxy in front of a service that can execute real API calls.

The HTTP transport does require a bearer token, which is the "required authentication" Grok's setup asks for:

swy mcp token            # print the current token
swy mcp token --rotate   # invalidate it and issue a new one

Three things to get right before you expose anything.

Treat the token as a production credential. Anyone holding it can invoke whatever your allow list permits. Rotate it if it has ever been in a chat window, a screenshot or a support ticket.

Terminate TLS at the tunnel. The local transport is plain HTTP on loopback, which is fine on loopback and not fine across the internet.

Assume the endpoint will be found. Public means public. The protection is not obscurity, it is the allow list and the policies behind it.

Why the allow list is the actual answer

The reason this architecture is defensible at all is that exposing the server does not expose your APIs. It exposes the operations you explicitly permitted, and nothing else.

swy init --mode=sandbox

swy get stripe
swy discover "refund a charge"        # find the operation
swy info stripe.refund.create3        # check its real parameters
swy add method stripe.refund.create3  # allow exactly this one
swy auth connect stripe

Only methods added with swy add method can run. If Grok asks for anything else, the call fails at the runtime before a request reaches the provider. A server with three allowed methods is a server that can do three things, however it is reached.

Then a policy, because an allow list permits an operation and says nothing about scale:

{
  "id": "big-refunds",
  "target": ["stripe.refund.create3"],
  "when": { "field": "amount", "operator": ">", "value": 50000 },
  "action": {
    "type": "REQUIRES_APPROVAL",
    "message": "Refunds over 500.00 need approval"
  },
  "approval_timeout": "2h"
}

And the credential never reaches Grok at all. It sits in ~/.swytchcode/credentials.db on the machine running the server, outside your project, injected when a call executes. There is no .env file and nothing secret crosses the tunnel. That separation is the whole point of credential brokering for AI agents.

The default agent tool profile exposes seven tools, discover, info, exec, list, search, add and a read-only policy, and those seven reach every integration in the catalog. Worth noting the add tool is in that default set: it lets the model extend the allow list. For an exposed server, decide deliberately whether you want that, and check swy audit policy regularly either way.

What xAI does not document

Worth listing, because the absence is as useful as the presence when you are planning.

The custom MCP section does not specify transport options, authentication methods, rate limits, request-size limits, tool-count limits, or what permission scope a custom connector receives. The "Grok will request only the permissions it needs" language appears in the built-in OAuth section, not the custom one.

So treat anything beyond "a URL and some authentication" as unverified until you have tested it. In particular, test what happens when your server is slow, when it returns an error, and when it exposes more tools than Grok expects.

Should you do this?

A straight answer rather than a pitch.

Reasonable: a read-mostly server exposing a handful of internal operations, behind a token, over TLS, with an allow list of five methods and a log you own.

Think harder: anything where the allow list includes operations that move money, delete data or send outbound communication. You can do it, with approval policies on those specific methods, but the correct amount of caution is more than you would apply to a local editor setup.

Probably not: exposing a runtime connected to production credentials because it was quicker than building a proper internal service. The convenience is real and so is the attack surface.

The broader version of this reasoning is in a security checklist before connecting any AI assistant to company data, and what a connector grant does and does not cover is in connect Gmail to Grok.

Keeping a record

Because an internet-reachable execution surface is exactly the thing you will be asked about later:

swy audit network   # what ran, with status and timing
swy audit policy    # what was denied or held, and by which rule

The fields worth keeping are in logging every API call an agent makes. The one that matters most here is the policy decision with its rule version, because that is the part you are accountable for rather than the provider.

FAQ

How do I add a custom MCP server to Grok?

Go to grok.com/connectors, click New Connector, select Custom, then enter your MCP server URL and complete any authentication it requires. Grok then discovers the tools the server exposes. On Business and Enterprise plans a team admin provisions the connector in the cloud console first.

Does Grok support local MCP servers?

No. xAI's documentation states the server must be reachable over the public internet, and points to a tunnelling service for servers running locally. This is the main architectural difference from editors like Cursor or Claude Code, which start a local process and talk to it over stdio with nothing exposed.

Can I connect Grok to Swytchcode?

Yes, with a deliberate step. The MCP server is stdio by default and its HTTP transport binds to localhost, so reaching it from Grok means putting a tunnel or reverse proxy in front of it with TLS. The bearer token at ~/.swytchcode/mcp_token serves as the authentication Grok asks for. Treat that token as a production credential.

Is exposing an MCP server to the internet safe?

It is as safe as the allow list behind it. Exposing the server does not expose your APIs; it exposes the specific operations you permitted with swy add method, and nothing else. Add TLS, rotate the token, keep the allowed method list short, put approval policies on anything destructive, and read the audit log.

Does Grok see my API keys?

No. Credentials stay in the local store on the machine running the server and are injected when a call executes. Nothing secret crosses the connection to Grok, and there is no .env file in the setup.

What limits does Grok place on custom MCP connectors?

None that xAI documents. The custom MCP section lists no tool-count, rate or request-size limits, and does not describe the permission scope a custom connector receives. Plan as though limits exist and find them by testing rather than assuming they do not.

How is this different from Grok's built-in connectors?

The built-in connectors for Google Workspace, SharePoint, Outlook, OneDrive, Notion, GitHub and Linear give broad account-level access with an on-or-off switch. A custom MCP server gives you an explicit list of operations, a policy layer and an audit trail you own, at the cost of running an internet-reachable service yourself.

Setup commands are from the Swytchcode MCP docs. Grok's custom connector behaviour is described from xAI's own documentation rather than linked.