Grok Bot vs ChatGPT vs Claude Connectors: What Each One Can Actually Do

Comparing assistant connectors by counting them is the wrong instinct. The number in the list tells you how quickly you can get started. What matters three months later is the permission model, who can revoke a connection, and whether you can reconstruct what happened.

On those, the three are closer together than their marketing suggests, and they share one gap.

The built-in lists

Grok launched connectors on 6 May 2026 across Web, iOS and Android with seven: SharePoint, Outlook, OneDrive, Google Workspace, Notion, GitHub and Linear. Google Workspace covers mail, documents, spreadsheets and events as one read-and-write grant. SharePoint is the only one with an explicit write toggle, where read access lets Grok search and synthesise and enabling write lets it create and update documents, lists and pages.

ChatGPT organises this around apps and plugins rather than a fixed connector list, where an app connects ChatGPT to an external service and a plugin packages capabilities into a workflow that can include apps, skills or both. Some apps require their own sign-in. The practical catalog is larger and more fluid than Grok's seven.

Claude connects through MCP as the primary mechanism rather than a separate connector concept, which makes the boundary between "built-in connector" and "custom server" less meaningful than it is elsewhere.

The honest summary: if your need is mainstream SaaS, all three will cover it. The list length is not the deciding factor.

The permission models

This is where they differ in a way that should affect your choice.

ChatGPT's three-way setting is the most granular of the three. The distinction between "allow read actions" and "allow low-risk actions" is a genuine attempt at tiering, and it is more than an on switch.

Grok's is the simplest. A connector is on or off, with SharePoint's write toggle as the exception. The Business and Enterprise provisioning step is a real control though: members cannot add connectors until an admin has provisioned them centrally, which is a stronger position than per-user consent.

Claude's model leans on per-call approval, which is granular in a different way: rather than configuring a tier up front, you see tool calls as they happen.

Custom MCP servers

All three accept a server you run. The constraint worth planning around is the same in every hosted case: the server has to be remotely reachable.

Grok's documentation is the most explicit about it, stating the server must be reachable over the public internet and pointing to tunnelling for anything local. ChatGPT's custom MCP setup has changed through 2026, with the developer-mode requirement reportedly removed, and OpenAI's own help centre does not document the custom MCP path at all, so check their developer documentation for the current steps rather than any blog including this one.

The exception is editor and desktop clients, which start a local process over stdio and expose nothing. That is a meaningfully different security posture, and it is why connecting a runtime to Cursor is a smaller decision than connecting the same runtime to a hosted assistant. We went through the Grok case in detail in Grok Bring Your Own MCP, and the editor side is in connect Cursor, Claude and any AI tool to 363 APIs with one MCP server.

The gap all three share

Here is the thing none of them does, and it is the thing that matters most once an assistant touches anything irreversible.

A grant decides whether the assistant may act. It does not decide how much.

None of these models expresses "allowed, but not above this amount without a human." ChatGPT's "low-risk actions" tier is the closest, and it is a category rather than a threshold you define. There is no built-in way to say that refunds under $500 proceed and refunds over $500 wait for approval, or that sending to more than fifty recipients needs a second pair of eyes.

For personal use that is fine. For an assistant connected to a shared mailbox, a payment system or a CRM, it is the gap to close, and closing it means putting something between the assistant and the action that evaluates a rule at execution time:

{
  "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"
}

A rule in version control, checked when the call runs, rather than a sentence in a prompt. The argument is in a prompt is not a policy and the pattern in policy-as-code for AI agents.

What to compare instead of connector counts

Four questions, in the order they will matter to you.

Who can revoke it, and how fast? Grok's admin provisioning on Business and Enterprise is a genuine advantage here, because central provisioning implies central removal. Per-user consent flows mean per-user cleanup.

What is written down, and can you get it out? An assistant's chat history is not an audit trail. You want a record from whatever sent the request, including the calls that were refused. Logging every API call an agent makes has the fields.

What is the blast radius of the broadest grant? Grok's Google Workspace connector is read and write across mail, docs, sheets and calendar in one approval. That is a larger single grant than it appears when you are connecting it for inbox summaries.

Does read access imply action? In all three, yes, if the assistant also holds an action-capable connector. Content an assistant reads can carry instructions, so the combination is what you evaluate, not each connector alone. The full checklist is in a security checklist before connecting any AI assistant to company data.

Picking one

If the decision is genuinely between these three for connector reasons:

Choose on admin control if you are a company. Central provisioning beats a larger catalog.

Choose on permission granularity if the assistant is personal but the data is not. ChatGPT's tiering is the most developed of the three.

Choose on local versus remote if you are connecting something you built. Editor and desktop clients that speak stdio avoid exposing anything, which is a materially different risk profile from a hosted assistant reaching a public endpoint.

And in every case, assume you will need an authorization layer of your own for anything that spends money, deletes data or sends outbound communication, because none of the three ships one.

FAQ

Which assistant has the best connectors?

Depends what you are optimising for. Grok has seven built-in connectors plus custom MCP, with admin provisioning on Business and Enterprise. ChatGPT has the larger and more fluid app catalog plus the most granular permission tiers. Claude treats MCP as the primary mechanism, which blurs the line between built-in and custom. Compare on revocation, admin control and logging rather than catalog size.

Do Grok, ChatGPT and Claude all support custom MCP servers?

Yes, all three accept a server you run. The constraint for hosted assistants is that the server must be remotely reachable, which Grok's documentation states explicitly. Editor and desktop clients can start a local server over stdio instead, which exposes nothing and is a different security proposition.

Which has the most granular permissions?

ChatGPT, on the published models. Its options include always ask, allow read actions, and allow low-risk actions, which is more than an on switch. Grok is on or off per connector with a write toggle on SharePoint. None of them lets you set a numeric threshold above which a human must approve.

Can an admin control which connectors employees use?

On Grok's Business and Enterprise plans, yes: a team admin provisions connectors in the cloud console before members can use them. In ChatGPT, admins and owners can disable an app from workspace settings. Central provisioning is the stronger of the two patterns because it is allow-by-exception rather than remove-after-the-fact.

Is one of them safer than the others?

Not meaningfully, on the connector layer. All three share the same structural property: a grant decides whether the assistant may act, not how much. They also share the prompt-injection exposure that comes from reading attacker-controlled content while holding action-capable connectors. Safety differences come from what you add around them.

What does none of them do?

Conditional authorization. There is no built-in way to say an operation is permitted below a threshold and needs human approval above it, scoped to the specific operation. If your assistant can move money or delete data, that is the gap you close yourself.

Connector behaviour described here comes from each vendor's own announcements and documentation, named rather than linked. The Swytchcode side is in the MCP docs.