MCP and AI Agents Are the Conversation Your Technical Clients Are Already Having

Every partner has a client like this. They don't want a chatbot that just works out of the box. They want to know if it plugs into the CRM their sales team lives in, whether it can talk to the internal database nobody outside IT is allowed near, and if their own developers can build something custom on top of it once the basics are in place.

For a long time, the honest answer to some of that was "not really, not without a lot of custom engineering." That's changed. Model Context Protocol, or MCP, gives AI models a standardized way to reach external tools and data sources. Combined with an open API and real SDKs, it turns "can it connect to everything we already run" from a hard question into a yes.

This is a technical topic, but it's not a technical-only opportunity. If you sell or promote Text, this is one of the clearest ways to move a conversation from "here's a license" to "here's a project," and get paid for the difference. It's also one of the fastest-growing parts of how businesses are actually deploying AI right now, so understanding it well puts you ahead of partners who are still pitching on features alone.

What model context protocol actually is

Model Context Protocol was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external systems. Before MCP, every AI tool that needed to talk to an external system needed its own custom connector. Multiply that across every AI model and every tool, and you get what's sometimes called an N-by-M integration problem, too many one-off connections, none of them reusable.

MCP fixes that by standardizing the connection itself. People often compare it to a USB-C port. A USB-C port doesn't care whether you're plugging in a monitor, a hard drive, or a phone charger. It just provides one standard way to connect. MCP does the same thing for AI. Instead of building a custom bridge for every model and every data source, you build one MCP server, and any MCP-compliant AI application can use it.

The protocol has three major components. A host is the AI application itself, the thing managing user interaction and holding onto context. A client sits inside that host and maintains a dedicated connection to a server. And the server exposes the actual tools and data, the things an AI agent can call to look something up or take an action. Communication between them runs on JSON-RPC, a lightweight, well-established messaging format, so different programming languages and different LLM providers can all speak the same protocol without translation layers in between.

None of this is a niche experiment anymore. A year after launch, MCP had been adopted across the industry, with integration into products like ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code, plus deployment support from AWS, Google Cloud, and Microsoft Azure. By December 2025, more than 10,000 active public MCP servers were running, covering everything from small developer tools to Fortune 500 deployments. That same month, Anthropic donated MCP to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. Handing governance to an independent foundation, rather than keeping it in-house, is a pretty strong signal about how permanent this standard already is.

Why AI agents needed this in the first place

An AI agent isn't just a chatbot with a longer memory. It's a large language model paired with planning logic and the ability to break a request down into steps, decide what information it needs, go get that information, and act on it. That last part is the whole point. An agent that can only talk and never touch a real system is stuck reciting whatever it learned during training.

Think about what a support conversation actually needs. A customer asks about an order that shipped three days ago. A sales rep wants to know if a lead already exists in the CRM before reaching out again. An internal team wants a quick summary of every unresolved integration ticket without filing an engineering request to get it. None of that lives inside a model's training data. It lives in a live system somewhere, updated every minute.

That's the context problem, and it's the reason MCP exists. It gives AI agents a structured way to reach real time data, connect to a CRM system or an internal database, and pull back accurate answers instead of a best guess based on outdated information. It also separates tool implementation from model reasoning.

And because MCP maintains a live, two-way connection rather than a single request and response, agents can hold onto context across a multi-step task. Ask something like "find the open tickets for this account, summarize the pattern, and draft a reply," and the agent can move through each step using the same session, the same permissions, and the same understanding of who's asking.

This is also why MCP gets described as a building block for agentic AI rather than a feature of any one product. It's not tied to a single model or a single vendor. A team can build one MCP server for their support data and let any compliant AI application discover and use it, then swap out the underlying model later without rebuilding the connection from scratch. That kind of flexibility is exactly what makes the technology worth explaining to clients who are evaluating more than one AI vendor at once.

How Text built MCP support into the platform

Text runs a hosted MCP server built on top of the platform's workflow engine. That's not a roadmap item. It's something your clients' developers, or their AI tools, can connect to right now.

Here's the part worth pausing on: MCP tools connected through Text don't get a special, loser set of permissions. Every action runs inside the authenticated user's existing account permissions, restricted to their assigned roles, teams, and authorized resources. An AI assistant connecting through MCP operates under exactly the same security model as the human it's acting on behalf of. That matters, because "can an AI agent access our data" is usually followed immediately by "and can it access data it shouldn't."

On the tool side, the external MCP server currently exposes a curated, growing set of capabilities:

• Agents can search across the Text ecosystem or fetch specific resources directly.
• On the chat side, they can pull a full chat transcript, list archived chats with filtering, or pull tags off a chat.
• On the ticket side, they can find a specific ticket by ID, list tickets with filtering and pagination, or list a ticket's tags.

In plain terms: a client can ask "show me unresolved integration tickets" or "pull the transcript from this chat" and get a direct, structured answer, no query language, no engineering ticket, no waiting on someone else's schedule.

What the open API and SDKs add on top

MCP handles the conversational, natural-language side of things. The open API is what makes the deeper, custom builds possible.

Three APIs make up the foundation here, and each one covers a different job:

• Agent Chat API – builds custom agent apps, browses chat archives, and manages actions like banning a customer.
• Customer Chat API – powers an entirely custom chat widget, handling everything from joining a chat to posting messages.
• Configuration API – stores and manages license configuration, the settings layer other integrations build on top of.

Together, these three are what partners use to connect Text into a client's entire tech stack, whatever that stack happens to be. CRM, ecommerce platform, internal reporting tool, none of it is off limits. A client running a homegrown order management system doesn't need Text to already have a plugin for it. They need a developer who can wire the two together using the API that's already there, and that developer can be on your team.

For developers who don't want to work against the raw API, Text also ships two SDKs, one written in Go and one in TypeScript, both built specifically to make those three APIs easier to use. These aren't thin wrappers either. They're maintained in step with the current stable API version, they're open source on GitHub, and they come with real documentation in godoc and typedoc format rather than a folder of half-finished examples someone has to reverse-engineer. For a partner's dev team, that's the difference between a multi-week integration and a genuine starting point they can build from on day one.

Put MCP and the open API side by side, and you get two different doors into the same house. MCP is the door for natural-language, ask-and-answer access. The API and SDKs are the door for structural, custom-built integrations. A client rarely needs just one.

Where the earning opportunity actually sits

This is the pitch shift that matters. Selling a license is a transaction. Building an integration into a client's entire ecosystem is a relationship, and it's billable well beyond the initial setup.

MCP and the open API support bespoke reporting and custom dashboards as a project of their own, separate from whatever implementation work you're already doing for that client. A client who wants ticket data flowing into their own BI tool, or wants an internal Slack bot that can query Text directly, isn't asking for a bigger license. They're asking for a build. That's development time, and development time is billable in a way that reselling a subscription simply isn't.

It also changes who's in the room during the sales conversation. Technical buyers ask a very specific question early: Can it connect to everything we already run? For a long time, partners had to answer that carefully, hedging around what was and wasn't possible. Now the honest answer is yes, and you're the one who gets to build it. That's a stronger position to sell from than any feature comparison, because you're no longer describing the product. You're describing what you personally can deliver with it.

Picture how that plays out with a mid-market ecommerce client that already runs Text for support. Their ops team wants weekly reporting on ticket volume and resolution time inside the internal dashboard they already check every morning, and their dev lead wants a Slack bot that can pull a customer's chat history before a sales call. Neither of those is a bigger license. Both are a scoped build against the open API, priced and delivered on your terms.

What to flag before you pitch it

Being the partner who understands this space also means being straight about what comes with it. MCP's growth hasn't been without friction, and knowing the landscape makes you more credible, not less.

Security has caught up with adoption. The protocol's authorization spec was updated in March 2025 to make OAuth 2.1 the mandatory standard for authenticating remote servers, precisely because the original spec had no mandatory authentication requirements at all. And the risks are real: in September 2025, an npm package impersonating Postmark's official email-sending MCP server was found quietly BCC'ing every outgoing message to an attacker-controlled address, after building trust over more than a dozen clean releases before the malicious version shipped. It's a useful, concrete example of why tool poisoning and over-privileged servers get treated as real risks in this space, not theoretical ones.

That's also exactly why Text's approach is worth mentioning explicitly when you're pitching this to a security-conscious buyer. Rather than granting AI tools a separate, broader access level, Text enforces the connected user's actual account permissions, the same model the client already trusts, just extended to a new kind of client sitting on the other end of the connection.

Where this conversation goes next

Everyone has AI. Sell and promote AI that actually does something. MCP and the open API are two of the clearest, most concrete examples of that line in action. They're not a feature you have to talk a client into wanting. They're the answer to a question technical buyers are already asking you.

If you've been selling Text as a product, this module is your opening to start selling it as infrastructure instead, something a client's whole stack can be built around. Bring it up with the next technical stakeholder who asks what's possible, and let the answer be the pitch.