What Is MCP? Procurement's Guide to the Model Context Protocol

Every vendor demo this year seems to include the same slide: "MCP-ready." But I haven't met many procurement pros who understand what this means...

The Model Context Protocol (MCP) is an open standard that lets AI applications discover and use external tools and data through one consistent interface, instead of a custom integration for every system. That's the textbook answer.

This article gives you the version a procurement leader can act on: how MCP works, what it unlocks, how it differs from an API, what it won't fix, and what to ask a vendor before you approve anything.

The top-ranking explainers on this topic are written by developers, for developers. They spend pages on "JSON-RPC" and "transport layers"... This is too technical.

You need to know who can touch your supplier data and what an AI agent is allowed to do with it. So, this is a business article.

Where it shines: the ad hoc questions that take ages to answer because you export data from five systems into Excel and massage it until your own back is in knots... 😅 In my own testing, connecting an MCP server took about 10 minutes once access was sorted. Genuinely impressive.

To further illustrate, imagine a restaurant.

Picture your ERP as the kitchen. Each dish the kitchen can produce for outside orders is an API endpoint: get supplier record, create requisition, list open POs. The APIs are the meals in the restaurant.

Now picture a diner who has never been to this restaurant. That's your LLM or AI application. Without a menu, they'd need something resembling a waiter to know what the kitchen makes, how to phrase each order, and what the kitchen needs from them (how do you want that steak?). That all has to be hard-coded. And, every time the kitchen changes a recipe, the old order breaks.

MCP is the menu. It lists what's available, describes each dish in plain language, and groups dishes into sections so the relationships are explicit (appetizers, mains, desserts). An AI application reads the menu, picks what fits your prompt, and places the orders in sequence to satisfy your hunger for an answer. (See what I did there…)

The kitchen still cooks. But, the menu means the diner no longer needs a waiter who memorized everything (read: an expensive consultant developing an expensive interface).

The analogy only breaks in one place... A menu doesn't check your allergies. Whether you're allowed to order a dish is decided by the kitchen and the door policy, which in software means "permissions". So hold that thought... It comes back in the security section.

Before MCP, every AI application had to be wired to every tool separately. Databricks calls this the N×M problem: N tools times M AI clients equals a pile of custom integrations. MCP cuts it to N+M, because each tool and each client implements the MCP protocol once.

In procurement terms: say you have a company LLM (Microsoft Copilot) and four systems you'd like to connect it to (ERP, CLM, supplier risk, sourcing). Without MCP, you map every data object you want from each system (suppliers, contracts, risk scores, RFx events) and build dozens of one-to-one integrations. Every one of those custom connections also breaks when a vendor changes the underlying API. (Just like that Excel macro nobody dares touch…)

With MCP, it's four connections, and the agent can reach whatever each server exposes, within the permissions it's given. How much each server exposes is a separate question, and we'll come back to it.

Until recently, getting an AI agent onto your procurement data meant picking one of two compromises.

Option 1: use your suite's native agents. Your S2P suite has likely launched or announced its own. Some of them are useful for work that lives entirely inside that one system. But the vendor decides what the agent can see and do. You're using their agent, on their terms.

Option 2: build custom API integrations. IT wires your company LLM to each system's APIs, one endpoint at a time. That's the N×M problem above, plus a maintenance bill every time a vendor ships a release. It scales about as well as a spreadsheet... 😅

Both options cap what your AI can do, and someone other than you holds the cap. MCP lifts it.

Three pieces do the work:

As a user, you only ever see the host (Claude). The connector and MCP server work behind it.

A category manager types a question into an LLM-powered assistant. Here's what happens:

The manager never named a system. Didn't look up any tables. Didn't apply any filters... The agent found the right tools because the server's menu told it which data objects existed and how to ask for them.

An MCP-connected agent can do three things it couldn't reliably do before:

The difference from a report is freshness and reach. The agent works on live data across every object the MCP servers expose, not a 40-column export someone pulled last Tuesday.

In practice, that looks like:

The common thread: ad hoc, judgment-heavy questions that today mean logging into three systems and rebuilding the answer in Excel. (Yes, the knots in your back.)

That last bullet is also the riskiest... An AI agent that can act needs rules about what it may act on... Which leads us to MCP server coverage and "read vs. write".

A vendor that publishes an MCP server is telling you something good: it treats your data as yours to connect however you choose. In a market where data portability still gets treated as a threat, that's important...

It's also the minimum bar. A server that exposes three tools is technically an MCP server and practically a very short menu. Push on:

An LLM that reads supplier records is a reporting tool. An agent that can change bank details or release a payment is a fraud vector with a friendly interface.

When experimenting and deploying MCP Servers, start with limited scopes and permissions, then expand once the basics are stable. I'd go further for procurement. Launch read-only, and make every write action pass through a human approval step until you've watched it behave for months.

An agent needs three things from your data: it has to be clean, complete, and reachable. MCP solves the third. Only the third.

MCP connects an LLM to your data. It does nothing about the quality of that data.

Ask an agent for total spend with a global industrial supplier that lives under five vendor IDs, and it will faithfully return partial answers if it can't make the links easily. The menu is standardized. The food is still whatever your master data team cooked up.

Expect someone to use this as a reason to wait: fix the data first, then invest in access via MCP. It sounds prudent. But, it doesn't hold up.

Data quality already limits every tool you own: spend analytics, supplier risk dashboards, your CLM. MCP isn't uniquely exposed to the problem. It makes the problem visible, because the answer comes back in plain language instead of a chart nobody questions.

And an agent with MCP access is actually a useful data quality tool. It can find duplicates in the supplier master, flag contracts with missing fields, and surface inconsistent category codes... Very quickly! That's a reason to start, not to wait.

LLMs are statistical. They predict the most likely answer, which suits flexible, judgment-heavy questions and does not suit rules that must run the same way every time.

Three-way match belongs in your S2P suite's workflow engine. Run it through an agent and you add variability exactly where you need certainty. Use agents for ad hoc analysis and cross-system questions. Use the applications for repeatable process. The two work together.

MCP also doesn't decide when a tool gets used. That call belongs to the model and the application around it, which means you still need testing, guardrails, and clear rules about which decisions stay human... Because different models might make different calls about how to solve the same problem.

Someone has to own each server. When the CLM vendor changes an API, the MCP server needs an update, or the agent starts ordering dishes that no longer exist.

A well-built MCP server on a fragmented record still gives you fragmented answers.

MCP gives an AI a path into systems that hold your suppliers, contracts, pricing, and bank details. Google Cloud's guidance lists the security principles that matter:

One more procurement-specific risk: procurement agents read documents that suppliers write. If an agent can read a supplier-submitted PDF and also has write tools, text hidden in that file can try to steer what the agent does. Separate what an agent reads from what it can change.

And remember the menu. It doesn't check your allergies. Insist that the server enforces each user's existing permissions, down to the field. If a category manager can't see financial terms in the CLM, their agent shouldn't either. No single broad service account.

"MCP-ready" can mean a production server or a slide. Ask these:

If the answers to questions 4 and 6 are vague, you've learned what you needed to know. And a vendor that can't say where its application layer ends and MCP begins published a server as a checkbox, not a capability.

MCP is a menu that lets LLMs and AI agents find and use the systems and data you already own. It solves the access problem that has kept procurement AI stuck in proof-of-concept purgatory. It also puts a bright spotlight on coverage, permissions, data quality, and ownership, because an LLM will use whatever it can reach.

Start read-only. Partner with IT to ask the hard questions. Fix your data in parallel, with the agent's help.

Want the deeper walkthrough, with more procurement scenarios and the vendor checklist in a format you can bring to your next demo? Get the free ebook.