It’s been a bit since I’ve blogged, but…one gets busy at times. In addition to moving house, most of my screen time has been spent on finally getting my first iOS app online. I’m sure I’ll have plenty of entries on that subject soon.
But not yet. Today I want to talk a bit about MCP. I’m sure my fellow 80s trivia geeks will immediately think of the Master Control Program from the movie Tron. In this case, though, MCP is Model Context Protocol.
In a nutshell, MCP is an open standard for connecting AI applications and agents to external systems. An AI application equipped with an MCP client can connect to an MCP server, discover the tools, resources, and prompts it exposes, and use those capabilities to retrieve context or perform approved actions.
For a very practical example, consider the insurance industry. An insurance company agent often has to check several independent systems to get a complete view of a single customer: data around policies, claims, billings, and other domains are often found in different systems, often provided by different vendors.
If each system exposes high-quality, approved customer information tools via the MCP protocol, an agent can find relevant information for questions such as, “Why was this customer’s claim denied?” The agent can check the claim system for relevant notes, billing system for missed payments, policy system for coverage status, the CRM for communications, the legal document library, etc.
There IS an important caveat: MCP does not, by itself, determine that Customer 11782 in one system is the same as Account C-4911 in another. The company still needs a reliable identity resolution method, such as a common customer identifier or master data service. That problem has to be addressed, with or without MCP.
An MCP server can also expose related tools that the agent can use to take action, rather than only consuming information; the agent isn’t simply a new way of creating reports.
Compare this approach to typical BI. If I’m the business analyst charged with creating a report to help someone investigate denied claims, I need to have:
- Knowledge of each system’s data scheme or APIs.
- Access to each system, likely managed individually.
- Time invested in developing queries for each.
- A data ecosystem process that ensures I’ll somehow be notified when changes are made upstream.
- A report consumer who’ll take the appropriate action based on my report’s insights.
The BI report is great for historical analysis and aggregating dashboards. For an interactive, operational workflow, however, an agent using the tools offered by an MCP server may complement or outperform a static report.
A common physical analogy is USB. Before USB, the machine I used to play Duke Nukem was connected to my modem with a DB-25 serial cable, the mouse with a DB-9, keyboard with a PS/2 port, hard drive through a SCSI connector, and camcorder via FireWire.
Along came USB, and suddenly, my Pentium could more easily work with compliant devices. Like the AI agent in the insurance industry, once I was attached to a system with broad use of a consistent standard, I was able to get to the fun far more quickly…
MCP may play a similar role for AI. It’s important to note that MCP doesn’t eliminate all integration complexity; it relocates and standardizes part of it. But the potential benefit is similar to the use of USB: less time building a different connector for every combination of AI application and enterprise system, and more time using those connections to perform useful work.

Leave a comment