Season 2 · Episode 4 · Integration

MCP: superpowers inside your company

MCP standardizes how an assistant discovers and uses capabilities. It includes optional HTTP authorization; business permissions, approvals and logging still need their own design.

Xophia teamUpdated 5 min read

A controller opens Claude in her browser and types: “Which invoices over 90 days do we have with our ten largest customers, and which of them bought this month?” The assistant doesn't answer with generalities. It queries the real receivables in the ERP, matches them against CRM sales, returns a table and offers to draft a collections email for each customer. When she approves, the drafts are ready in the system, with a record of who asked for what.

The scene is a composite, but it's no longer science fiction. It's what the Model Context Protocol makes possible when a company exposes its systems in an orderly way.

What MCP is, without jargon

MCP is an open standard Anthropic introduced in November 2024 to reduce custom integrations between assistants and systems. It defines a shared interface for servers that offer tools, resources and prompts. That lets compatible clients reuse part of an integration, although clients may support different features and authentication still needs configuration.

The specification includes optional authorization for HTTP connections, using an OAuth-based flow; local stdio connections obtain credentials from the environment. A protected HTTP server must validate the token and ensure it was issued for that server. None of this decides which invoices a person may read or who approves a payment: the MCP server and business systems must enforce those rules.

A governed MCP connectionThe protocol carries capabilities; access policy and logging are implemented around them.
  1. ClientA compatible assistant requests a tool for an identified user.
  2. MCP serverIt validates identity, scope and parameters before invoking a capability.
  3. SystemThe API applies its permissions; sensitive actions wait for approval and leave a record.

The common analogy is a USB-C port for AI: a shared interface instead of a separate integration for every combination. It helps explain compatibility, but it doesn't mean every server works without adjustment in every product. Check which features each client supports before designing a critical process around them.

Why it matters: AI goes where your team already is

An MCP integration can bring company capabilities into an AI client the team already uses, if that client supports the features needed. A person asks in plain language and the assistant can query or propose actions on authorized systems. Test compatibility and the approval flow before promising everything will happen on one screen.

The Claude-in-a-browser scene has a network constraint: its remote MCP connector connects from Anthropic's cloud, not from the user's computer. The MCP server must be reachable from Anthropic's IP ranges; one confined to the corporate VPN will not connect by itself. Before promising ERP access, design a protected, narrowly scoped remote entry point without exposing the internal API directly, and test connectivity, authentication and permissions.

MCP can carry authorization. The server and connected systems remain responsible for enforcing business permissions.

Analyze and act

Capabilities can be separated into two groups. Analyze: query governed metrics, cross sources, explain a variance, find exceptions. Act: prepare a draft, record an action, update a status, trigger a workflow. Queries can add value without writing to systems. Execution may save work, but it also adds risk and calls for stronger controls.

Power requires control

A badly designed MCP server can expose unauthorized access. When a tool acts for a person, bind the call to their identity and enforce their permissions; an autonomous process can use a narrowly scoped service account. Tools should validate parameters and expose only necessary actions. High-impact actions need approval according to business policy. Records should reconstruct who requested what and the result without copying unnecessary sensitive data.

Those controls reduce risk; they don't remove it. Before opening a tool, test insufficient permissions, malicious content, system errors and rejected approvals. Only then can the assistant become a useful interface for specific company tasks.

How to start

A first MCP server can be limited to read-only queries on authorized sources. If the case uses business metrics, govern their definitions. Add actions once answers, permissions and failures have been tested, with human approval where impact demands it. Trust is built with records and results, not promises.

For Monday

  1. Ask five people from different teams what they'd ask an assistant with access to the company's systems.
  2. Split those questions into ones that only need a query and ones that need an action.
  3. Pick three query-only ones as the scope of a first, read-only MCP server.

Sources and context

Related reading

See the platform

The scenes in these episodes are composites of common situations, not customer cases. Any figures in them are illustrative.

Do any of these episodes sound familiar?

In 20 minutes we review your case and you leave with a map of what stays, what connects and what's worth replacing.

Xophia

Tell me what your company does.

Let's understand what you need and prepare an example you can explore before talking with the team.

Xophia is preparing a response…

You are chatting with an AI agent. Your messages are sent to generate a response. Avoid sharing confidential information.