MCP integration for customer-facing agents

MCP moved the integration problem; it did not remove it

Connecting a system to an assistant used to mean writing an adapter for that assistant, then writing it again for the next one. The Model Context Protocol replaced the adapter with a contract: a server describes the tools it offers, any compliant client can call them, and the two sides stop having to know about each other. If your team already runs an MCP server, the expensive and unglamorous part is behind you.

What is left is a product question rather than an engineering one. You have tools an agent can call. The open items are who that agent is, who operates it on a Tuesday afternoon, and who answers for what it says to a customer who is already annoyed.

Two directions, and they are not the same decision

"MCP integration" gets used for two different things, and conflating them is how a quarter gets spent on the wrong one.

• Consuming: your agent calls out to MCP servers you already run, whether that is catalog, orders or internal tooling. This decides what the agent can do.
• Being consumed: your agent is reachable as an MCP server, so it appears as a tool inside a client someone on your team already has open. This decides who gets to drive it.

What happens at the connection boundary

An MCP server is attached per agent rather than per account. The tools a given conversation stage can reach are a deliberate choice, not something inherited from a global list, which is the difference between an agent you can reason about and one you audit after an incident.

Tools are discovered live from the server before the connection is saved. A server whose shape has changed tells you what it now exposes, instead of failing quietly during a customer conversation three weeks later.

Authentication is where these integrations usually stall, because the server you want to connect was built for your own backend rather than for a third party. Four modes are supported: static headers, OAuth2 client credentials, a locally minted JWT, and the full authorization-code exchange with redirect and refresh. Transport is remote MCP over HTTPS.

The agent is the part you were not planning to build

Teams who arrive here have generally built the servers already. What they have not built, and on inspection do not want to build, is everything in front of them: conversation design that survives real customers, grounding in a catalog that changes daily, channel plumbing across web, WhatsApp, voice and email, escalation that hands a human the context rather than a transcript, and enough observability to answer whether the agent is telling customers the truth.

That is the whole trade. You keep your stack, your servers and your client; we bring the agent and the operational surface around it.

Building the agent is itself an MCP surface

The tools our own copilot uses to build and run an agent are exposed over MCP: create a flow, add a stage, set the examples that shape its behavior, write an SOP, change a setting, hold a test conversation, read back what happened in production. The dashboard is one client of that surface rather than the source of truth, so an engineer can build and operate an agent without ever opening it.

Where this is already running

Kestrel RMS is real estate portfolio management software. The part of that engagement with the heaviest daily use is an MCP server putting Kestrel's own capabilities inside Claude Desktop, so the platform is operated from the tool its users already have open rather than only through its own screens. Modalsports runs an MCP server exposing their betting platform to agent tooling, next to live trading agents. Both are on the customers page.