Add your own MCP server
Connect any remote MCP server so its tools become available in chat, Code and Cowork
Beyond the prebuilt integrations, you can connect your own remote MCP server. Its tools then show up like any other integration, in chat and in the desktop products.
Model Context Protocol is the open standard for exposing tools to an AI assistant. If a service offers an MCP endpoint, this is how you plug it in without anyone writing an integration for it first.
This needs the permission to create MCP servers. If you do not see an Add option under Integrations, your role does not include it, so ask an administrator.
Adding one
Open Integrations, in the browser under Settings, in the desktop app with
Cmd/Ctrl+Shift+E.
Enter a name and the server's URL. The name is what you and your colleagues will see in the list, so name it after the service rather than after the protocol.
Authentication
| Method | When to use it |
|---|---|
| OAuth (recommended) | The server supports OAuth. Each user signs in themselves, with their own permissions |
| API key | The server expects a key in a header or a query parameter |
| Bearer token | The server expects a fixed token in the Authorization header |
| None | A public server that needs no credentials |
OAuth is the default and usually the right choice. It only needs the name and the URL: the address of the authorization server is derived from the server's own URL, at the well-known path virtually every MCP server uses. Each person who uses the integration signs in as themselves, so nobody shares a credential and access follows whatever the service already grants them.
For API key, say where the key goes: as a header or as a query parameter, under which name, and with a prefix if the service wants one, for example Bearer .
Everything else, the transport, an explicit authorization-server address, OAuth scopes, and your own client ID and secret, is in the collapsed advanced section. You rarely need it, and if a value there fails validation the section opens itself instead of the save looking like it did nothing.
Transport
Left alone, the modern streamable HTTP transport is used. Older servers that only speak HTTP with server-sent events work too, and that is what the transport option in the advanced section is for. If a connection attempt fails with a transport error, this is the first thing to try.
Sharing it with your team
There are two independent things you can share, and mixing them up is the most common source of confusion:
| What you share | What the recipient gets | Where |
|---|---|---|
| The server (definition) | It appears in their integration list, and they connect it with their own credentials | The "…" menu on the integration in the overview |
| The credentials (API key) | They use your key without ever seeing it | The "…" menu on the integration's detail page |
A common combination: you add the server and share the definition so your team can see it, and you also share the key so everyone uses the organization's credentials without being able to read them. Both shares are managed separately and can be revoked at any time.
Using it
Once connected, the server's tools are available in chat, in Code and in Cowork, through the same server-side dispatcher as every other integration.
Every action that changes something in the connected service is approval-gated, separately from file changes. In the desktop products, Auto-approve connections waves those through if you would rather not confirm each one.
An MCP server is code someone else runs, and its tools can act on your behalf. Only add servers you trust, and prefer OAuth so it acts with your own permissions instead of a shared key.
When it stops working
- A tool disappeared: the server changed its tool list. Open the integration's detail page to reload it.
- Authentication errors: for OAuth, disconnect and connect again to run a fresh sign-in. For an API key, check whether the key was rotated.
- The server cannot be reached: it has to be reachable over public HTTPS. A server on a private network is unreachable from our infrastructure, and is deliberately blocked as well.
- The URL is rejected when you save: the hostname has to resolve in public DNS. A name that only exists inside a VPN or an overlay network — a Tailscale
*.ts.netname, an internal DNS zone — resolves on your own devices but not from the internet. It is never about the domain's ending; no top-level domain is blocked. The error message says which of the two applies.