Local vs Remote MCP Servers, and Signing In with OAuth

Choose between MCP Servers on your machine and on the internet, understand the OAuth flow the MCP spec defines, and what to configure safely.

Your accounting team wants AI to read Excel files on each person's computer, while your sales team wants AI to pull customer data from a shared CRM. Both use MCP, but installation and login work very differently. Choose wrong and you end up with a system that is hard to use, or a security gap you did not notice.

What are local and remote MCP Servers?

The MCP Architecture documentation explains that Servers can run either on your machine or on the internet.

• Local Servers run on the same machine as the AI app, use the stdio transport and typically serve a single Client, for example the filesystem Server that Claude Desktop launches itself
• Remote Servers live on the internet, use Streamable HTTP and can serve many Clients, for example the official Sentry Server running on Sentry's platform

Which one should you choose?

Local fits when

• The data is on the user's machine, such as files in a work folder
• One person uses it, or you are still experimenting
• You accept installing it on every machine, and the official guide notes that many Servers also need Node.js

Remote fits when

• Many people use the same data, such as a CRM or ticketing system
• It must work from the web or mobile, not just a desktop app
• You need per-user authentication and permissions

Signing in with a local Server

The MCP Authorization specification says stdio Servers should not use the OAuth flow and should instead take credentials from the environment, such as an API key set in a configuration file. The key point: a local Server runs with the user's account permissions, so it can do anything the user can do.

How OAuth works with remote Servers

For HTTP transports the spec uses OAuth 2.1, with the MCP Server acting as the resource server and the MCP Client acting on the user's behalf. Roughly, the flow is:

1. The Client sends a request without a token and receives a 401 response pointing to the Protected Resource Metadata document
2. The Client reads that document to find the authorization server, then fetches that server's metadata
3. The Client registers itself. The latest spec recommends Client ID Metadata Documents; Dynamic Client Registration is still supported but deprecated
4. A browser opens the login page, where the user authenticates and grants access. The Client uses PKCE and states which Server the token is for (the resource parameter)
5. The Client receives an access token and attaches it to every request. The Server must verify the token was issued for it

The advantage is that the AI app never sees the user's password, and access can be revoked later.

Example: a mid-sized accounting firm

An accounting firm uses both at once. Each accountant installs a local Server that can read only the client folders they manage. The firm's job-tracking system is exposed as a remote Server that everyone signs into with their company account via OAuth. When someone leaves, IT disables one account and their AI access disappears with it.

Things to watch out for

• Remote Servers must be reachable from the internet. The Claude Help Center explains that Claude connects to remote connectors from Anthropic's cloud, not from your device. A Server behind a VPN or firewall will not connect unless you allowlist the relevant IPs.
• Request the fewest scopes possible. The Security Best Practices document recommends starting with basic permissions and requesting more only when needed, instead of asking for everything up front.
• Never pass tokens straight through. A Server must not accept tokens that were not issued to it.
• For one-click local installs, you should see the full command that will run before you confirm.

Local is one person's convenience. Remote is permission management for a whole team. Choose based on where the data lives and who needs it.

How to get started

1. Identify whether the data you want AI to use lives on users' machines or in a central system
2. For a central system, check whether the vendor already offers an official remote MCP Server before building your own
3. If you build one, use your organisation's existing authorization server instead of writing a new login system
4. Test the login flow with a low-privilege account first, then expand

For more background, read What is MCP and Building your first MCP Server to see the whole picture before you decide.