Ishmael Interactive

The Scientific Method of Business

The CX of MCP, LLMs, and APIs

Welcome to another week of Software Engineers Solve CX Problems™️. Well, almost: complete solutions through technology almost never happen. But engineers and engineering companies frequently think they do and tell us so in the marketing. The past couple of weeks have been no exception.

The Release

A few weeks ago, Anthropic, the makers of Claude.ai, a generative artificial intelligence large language model or LLM, launched a standard for integrating software services with LLMs. This means that software like Slack and Google Drive could be easily connected to common generative AI models like Claude, Gemini, and Llama. Anthropic calls this the Model Content Protocol, or MCP.

This is important because until a few weeks ago, if you wanted to use an LLM with a software service, you had to hook them together manually. This “hooking together” was done through Applied Programming Interfaces, or APIs.* This worked, but it was tedious and prone to enormous complications once you had more than a few services’ APIs connecting into your LLM(s)’ API(s).

Enter the MCP, and suddenly any number of software services your organization uses could be connected to the LLM(s) your organization uses quickly and seamlessly. This is because the MCP is a standard set of rules that all developers of software services and all developers of LLMs could build towards. So instead of every service and every LLM company having their own ways of providing connections, each service knows it can simply build their API towards the MCP’s connections, and the MCP will connect them all together.

But aside from wizzy hookups between services and LLMs, what purpose does it serve? Backend software company Zapier has an answer.

The Business Application

Zapier is a company providing automation for software tasks without coding. They use events they call “triggers” to start workflows they call “zaps”, which is unforgivable. They are very excited to use MCP to help their customers link up LLMs across multiple services and use Zapier to do it automatically. This means that if a customer fills out and submits a form to one part of an organization, Zapier can ensure that the information is entered into a database, notify a client services person on slack (a standard Zap), and that the text for a follow up email is produced for the client services person. This last part is done by MCP translating between the database and email software. If you want to customize that Slack notification as well, that, too, would be handled by the MCP and an LLM working together.

The sell here is that MCPs will create actual AI agents, which everyone has been talking about for months but were, as discussed previously, very tedious to set up. The business purpose is that client-facing humans will be freed from monitoring notifications and composing emails in response to actions, and that the software-facing humans will be freed of tedious connection and maintenance needs.

So far, so good. But let’s look a few months beyond launch and understand how this might work in organizations and for customers over a few fiscal quarters.

The Problems

There are three major problems that all organizations will have to resolve:

  1. Who architects these workflows?
  2. Who maintains and governs them?
  3. Who maintains and governs the model Content Protocol itself?

The first two are organizational problems. The first task will probably be taken on initially by the best technical team the organization can muster. Likewise, the governance will likely be overseen at the highest levels. But not for long.

First rate development teams move on to new Everests to climb, and C suite will have new Rubicons to cross. For this reason, each organization will need to develop their own robust governance structure for these tasks to ensure that the workflows can be maintained, developed, and sunset in ways that serve each division and business line using them. Without this structure, you can be sure that teams and individuals will hop on the workflow bandwagon, each in the name of optimization. The result will be a spaghetti of integrations and workflows, none of which is well-coordinated and with the customer at its center.

The third question is a larger one. If a standard is made, who supports it? In the history of standardization, government support is almost always the safest answer. From the establishment of the mile by ancient Romans to that of http in 20th century Switzerland, standards flourish on the long timelines of governments.

Contrast this with the fate of so many privately held “standards”. Microsoft’s .docx is widely used, but it is constantly under siege from another, competing “standards” in the open model. Because of this, one can never seem to maintain formatting across simple documents.

On the other side of the spectrum is the iOS App Store, a walled garden operating system from Apple which has just lost its shirt in court. It is also valued and widely used, but adhere to Apple’s rigorous rules or see yourself barred outside and engaged in lawsuits. It is obvious from these examples that privately held standards rarely live up to, forgive me, standard.

The Solutions

And so if Anthropic is determined to make MCP a standard, they should work with international bodies to make it so. It is time we had a standard for backend processes, anyway; everyone, from client services to backend engineers, hates the drudgery of figuring out the hook ups between services.

For companies looking to implement MCP to gain efficiencies, do so, but with caution. In the medium term, this standard could go the way of so many before it, becoming either sclerotic, fixed, and a hindrance to the market or completely walled off from it. More immediately, without governance, this integration to end all integrations threatens not to increase internal efficiency and produce gains for customers, but to simply proliferate internal tasks and cause more and more to be done about less and less. For a historical parallel, we need only to look at email and Slack to be sure of that.

*These names and acronyms are not descriptive of what any of these systems do, which is why it’s important to name them fully and call them what they are.