How to connect Claude to business software with MCP

What the connection actually is

Three parts are involved, and naming them avoids most confusion later. The host is the Claude application. Inside it, a client is created for each server you connect, and that client talks to exactly one server. The server is the business system's MCP endpoint, a single HTTPS URL that accepts JSON-RPC messages. Claude's clients run in Anthropic's cloud, not on your machine, which is why the server has to be reachable from the public internet; a system on a private network needs Anthropic's address ranges allowlisted before any of this works.

The URL is the only thing you need to know in advance. For a Sois workspace it is the workspace address followed by /api/mcp. Other products publish theirs in their documentation; one ending in /sse indicates the older transport, which Claude still accepts but which the specification now marks as deprecated in favour of Streamable HTTP.

The walkthrough, minute by minute

1. Paste the URLIn Claude, open Customize, then Connectors, choose Add custom connector, give it a name and paste the server's HTTPS address. In Claude Code, run the mcp add command instead.
2. Claude probes the serverClaude sends a request with no credentials. A protected server answers 401 with a WWW-Authenticate header pointing at its protected-resource metadata. Claude reads it and marks the authentication settings it detected.
3. Claude finds the authorisation serverThe metadata names the authorisation server. Claude fetches that server's own metadata to learn the authorize, token and registration endpoints and the PKCE method it requires.
4. Claude identifies itselfClaude either presents Anthropic's hosted client metadata document, or registers dynamically, or uses a client ID you entered. Nothing for you to do unless you chose the last option.
5. You sign in and consentClaude opens the system's sign-in page in your browser. You authenticate as yourself and approve the scopes shown. The system redirects back with a code, Claude exchanges it for a token bound to that server, and keeps the refresh token.
6. Claude lists the toolsWith the token attached, Claude calls tools/list and receives the tools this system offers to you. They appear under the connector, each with a permission you can set.
7. First requestAsk for something. Claude picks the tools, asks for approval on the first call to each unless you chose Always allow, and the system checks the call against your permissions before doing anything.

Steps two to five are the OAuth 2.1 flow the MCP authorisation specification requires of HTTP servers, and the reason there is no token to paste. The 401 challenge looks like this on the wire, with the metadata address and, optionally, the scopes the server wants.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://acme.sois.ai/.well-known/oauth-protected-resource",
                  scope="mcp"

The challenge a Sois workspace returns to an unauthenticated client. The client follows the resource_metadata address to discover the authorisation server; the scope value is the least privilege it should request first.

Two protocol rules protect you here without your involvement. The client must ask for a token for this specific server, using the resource parameter from RFC 8707, and the server must reject tokens issued for anything else, so a token for one system cannot be replayed against another. And the server must never pass your token on to a third service. The specification treats both as hard requirements, not recommendations.

Choosing the sign-in method

Claude's Add custom connector dialog offers a small set of choices once it has probed the URL. Most people never change what it detects, but it helps to know what each one means, because the authentication settings cannot be edited afterwards; to change them you remove the connector and add it again.

For Team and Enterprise plans the shape is the same with one extra step: an owner adds the connector under Organization settings, and each member then connects and signs in as themselves under Customize. The owner decides which servers exist; the member's actions still carry the member's own authority.

What Claude sees after connecting

The tool list is the whole interface. Each entry has a name, a description and an input schema, and Claude's model uses the descriptions to decide which tool a request needs and the schema to fill in the arguments. On a Sois workspace the list is filtered by your role and by the apps installed before it is returned, so a finance user sees tools such as searchInvoices, createInvoice, recordPayment and sendInvoiceReminders, alongside the contacts, inbox, calendar and task tools everyone has, and does not see the administrative tools at all. The specification permits exactly this: a server may vary the list by the credentials on the request.

Claude then layers its own controls on top. Under the connector you can set any tool to Blocked, so the model never sees it. In chat, each tool call asks for approval unless you have chosen Always allow for that tool, which Anthropic advises reserving for servers you trust. Research features can invoke connector tools without asking, so the guidance is to turn write tools off on the connector while a research run is in progress.

The same connection from Claude Code and the API

In Claude Code the command is claude mcp add --transport http sois https://your-workspace.sois.ai/api/mcp. The server is stored at local scope by default; --scope project writes it to a .mcp.json you can commit for the team, and --scope user makes it available in every project. Run /mcp to sign in through the browser, or claude mcp login sois from the shell. Connectors already added on claude.ai appear in Claude Code automatically under the same account, and administrators can mark individual tools as ask or blocked.

The Messages API is different in kind. Its MCP connector, in beta behind the mcp-client-2025-11-20 header, takes the server URL in an mcp_servers entry and an mcp_toolset in the tools array, and it supports tool calls only. There is no browser flow: you obtain the OAuth access token yourself and pass it as authorization_token, refreshing it as needed. That suits a service you run on behalf of users you have already authenticated. It is the wrong path for handing an end user a connection, which is what the custom connector exists for.

What Claude is allowed to do

After the walkthrough the useful question is not whether Claude is connected but what the connection can do, and the answer is set by the server. On Sois the answer is a person's permissions, enforced twice: once when the tool list is assembled, once when each call runs. The token was issued to you, so every action is attributed to you in the workspace's log with its inputs and its result, exactly as a person's would be. Spend is capped per integration where the workspace's own agent does work; when Claude does the reasoning, as it does over this connection, the workspace performs no AI on your behalf and charges nothing for it.

That is what makes it reasonable to let a model act: the permissions are the ones the business already maintains for people, and the connection inherits them.

When something goes wrong

• Sign-in loops or fails. Almost always the URL: a path that is not the MCP endpoint, or a server not reachable from the public internet. Check the address against the system's documentation and confirm it answers 401 with a WWW-Authenticate header.
• Tools are missing. The list is filtered by your role. If a colleague sees a tool you do not, the difference is permissions in the business system, not the connector.
• A call is refused. Read the error Claude reports. A permission refusal means the person you signed in as cannot do that; a validation error means the model can correct the input and retry.

Questions people ask

This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.