Hi {{FIRST_NAME|readers}},
Procurement was running low on acronyms. S2P, P2P, CLM, SRM, I&O…
So the AI world gave us another one: MCP. 😅
It shows up in LinkedIn posts, analyst notes and vendor release notes, usually with no explanation. Is it a product? A module? Something else you'll have to license?
Short answer: it's an open interface standard. It decides how the AI tools your company already pays for reach into your ERP, your CLM and interact with your supplier, contract or PO data.
And, honestly, it’s amazing for all those ad hoc questions that take ages to answer because you manually export data to Excel from 5 systems and massage it until you have knots in your back yourself…
(Can you tell I’ve been using MCP myself!?)
That makes MCP an acronym worth knowing for procurement teams.
Today, we're explaining MCP in plain business language, how it differs from the APIs you already have, and what it won't fix in your data.
Onwards!
📰 In this week’s edition:
🎥 Access your S2P Suite procurement data with an MCP (sponsored)
🤿 What is MCP? The Procurement Leader’s Guide to the Model Context Protocol
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye
Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.
Table of Contents
Introduction
Every vendor demo you sit through this year will include the same slide: "MCP-ready." Most procurement pros don’t know what that means. The room nods anyway. 😂
So, what is MCP? 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. And the biggest benefit? It literally takes 10 minutes to set up once you have the accesses. That's the textbook answer.
This article gives you the version a procurement leader can act on: how MCP works, how it differs from an API, and what to ask a vendor before you approve anything.
Here's the problem: the top explainers on this topic are written by developers, for developers. They spend pages on “JSON-RPC” and “transport layers”. What you need to know is who can touch your supplier data and what an AI agent is allowed to do with it… So expect a business article below, not a technical one.
What Is MCP? The Short Answer
MCP is a shared language between AI applications and the systems they need to reach: your ERP, your contract repository, your supplier risk tool, your sourcing platform. Anthropic introduced it in November 2024. Because it's an open standard, a connection built once can work with different AI assistants instead of being rebuilt for each.
If you read our breakdown of AI agents, you already know an agent needs tools to do anything useful. MCP is how those tools get plugged in without a custom project every time.
Most MCP explanations reach for a USB-C port analogy. I prefer a restaurant.
Picture your ERP as the kitchen. Each dish you can request from the outside is an API endpoint: get supplier record, create requisition, list open POs. The API are the meals you kitchen can produce.
Now picture a diner who has never been to this restaurant. Without a menu, they'd need to know what the kitchen makes, how to phrase the order, and what the kitchen needs from them (how do you want that steak?). Someone has to hard-code all of that, and every time the kitchen changes a dish receipt, the old order breaks.
MCP is the menu. It lists what's available, describes each dish in plain language, and groups dishes into sections, making the relationship between them explicit (appetizer, main, dessert, drinks, etc.). An AI agent reads the menu, picks what fits the request/prompt, and places the order in sequence to “solve your hunger for an answer” (see what I did there…).
The kitchen still cooks the meal. The menu just means the diner doesn't need a waiter who memorized everything (read: expensive consultant).
Where the analogy breaks matters too. A menu doesn't check your allergies. Whether you're allowed to order the dish is decided by the kitchen and the door policy, which in software means permissions. Hold that thought, because it comes back in the security section.
Why MCP Exists: The Integration Mess It Replaces
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 protocol once.
Here's what that looks like in your world. Say you have a company LLM (MS Copilot) and four systems (ERP, CLM, supplier risk, sourcing) you’d like to connect it to. You need to figure out all the data objects you want to get from each system (e.g. suppliers, contracts, risk scores, RFx events, etc.) That’s dozens of custom 1-to-1 integrations you need to build. With MCP, it's 4 connections and you get access to 100% of the data objects each system has to offer (based on your permissions).
Furthermore, every one of those custom connections breaks when a vendor changes the underlying API, or technical way to access each system object/action. (Just like that freaking Excel macro nobody dares touch…)
Right? Right…? 🧐
How MCP Works: Host, Client, and MCP Server in Procurement Terms
An MCP server is the piece that publishes the menu and passes orders to the kitchen via the APIs. It sits in front of a system and its APIs and exposes what that system can do in a standard format.
A Example: "Which Contracts Expire in 90 Days?"
A category manager types a question into an LLM-powered AI assistant. Here's what happens:
The manager asks: "Which supplier contracts expire in the next 90 days with no renewal owner?"
The LLM checks the connected MCP servers and reads the menu: a contract lookup tool and a supplier record resource are available in your S2P Suite.
The AI model picks the contract lookup tool and fills in the required fields, such as the date range (what your consultant or IT team traditionally had to map manually).
The server turns that request into a call to the S2P Suite's API for vendors, The S2P Suite sends back the results for the request.
The model reads the results, then calls the contract lookup API with the proper vendor IDs to find the owners of each contract, and writes the answer out for you in the LLM’s chat interface.
If you have bad data (e.g. missing contract owners), it tells you that too.
The manager never named a system. The agent found the right tools (S2P Suite) because it was connected to them and the “menu” (MCP Server) told it what existed as data objects it could use to solve the problem.
What an MCP Server Can Expose: Data, Actions, and Templates
A MCP server can put three kinds of items on the menu:
Resources: data the AI can read. A procurement policy, a category strategy, a training document.
Tools: actions the AI can take or calculations it can run. Create a requisition, calculate savings, trigger a supplier onboarding form.
Prompts: reusable templates for common tasks. A standard "run a supplier risk review" routine, for example.
Resources return data and don't execute anything. Tools can cause a side effect. That difference is the most important line in this article.
Read vs. Write: Where to Draw the Governance Line
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.
Databricks recommends starting with limited tool scopes and permissions, then expanding 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, not days or weeks.
MCP vs. API vs. RAG: What's Actually Different?
These three get confused constantly. In the restaurant:
API: the meal. A fixed endpoint that a developer wires up by hand. Traditional APIs expect the client to hardcode endpoints and update them when they change.
MCP: the menu. Servers publish what they offer, and AI systems can discover it at runtime instead of relying on predefined connections. MCP builds on function calling and standardizes it.
RAG (retrieval-augmented generation): the reference shelf. The AI looks things up in an indexed library, such as your procurement policy PDFs, before it answers. It reads. It doesn't order anything.
You don't pick one. Databricks describes organizations using RAG for stable reference content and MCP for live lookups and actions against current systems.
The policy chatbot is a RAG job. "Which POs are stuck in approval right now?" is an MCP job.
What MCP Will Not Fix
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 five partial answers. The menu is standardized. The food is still whatever your master data team cooked up.
That doesn’t mean you can’t use MCP to drive data governance and quality… In fact, it’s a great place to start with MCP Servers.
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.
And 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.
MCP Security Risks Procurement Should Care About
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:
User consent and control: people need to understand and approve what the AI accesses and does on their behalf.
Tool safety: tools can run code, so tool descriptions from an untrusted server shouldn't be trusted. Users should know what a tool does before it runs.
Supply chain security: the servers and the systems behind them are part of your third-party risk surface. A random community MCP server for your ERP deserves the same scrutiny as any unvetted vendor.
Monitoring and auditing: you need logs showing which agent called which tool, with whose access.
One more risk that the developer-focused explainers skip: 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 the user's existing permissions in the back end system instead of running on one broad service account.
7 Questions to Ask a Vendor That Claims "MCP Support"
"MCP-ready" can mean a production server or a slide. Ask these:
Is your MCP server generally available today, or is it a demo or roadmap item?
Which tools and resources does it expose, and which of them can write, change, or approve anything?
Does it inherit each user's existing permissions, or does it run on a shared service account?
Can we switch individual tools (APIs) off?
What gets logged, and can we trace an action back to a specific user and agent?
Who hosts and maintains the server, and what happens when your APIs change?
Which AI assistants can connect to it? Can we use the one IT already approved?
If the answers to questions 3 and 5 are vague, you've learned what you needed to know.
MCP is a menu that lets LLMs and AI agents find and use the systems and data you already own. It makes agents far easier to connect, and it puts a bright spotlight on permissions, data quality, and ownership, because an LLM will use whatever it can reach. Start read-only, ask hard questions, and fix your data in parallel.
Want the deeper walkthrough, with more procurement scenarios and the vendor checklist in a format you can bring to your next demo? We’ve got a free ebook for you.
👀 In Case You Missed It:
Episode 17 of the ProcureTech Unpacked podcast is LIVE!
PROCURETECH UNPACKED
The 5 Foundations of Agentic Procurement Teams
👀 In Case You Missed It…
The Last 3 Newsletters:
1/ Deploying AI Agents in Procurement Without Getting Burned
2/ Your Vendor Punch Out Catalogs Are Broken. Here's How to Fix Them.
3/ Your AI Agents Can't Outperform the Platform They're Built On
The menu is not the meal.
2 other ways we can help this week:
An MCP connection is only as good as the platform behind it.
In partnership with Zip, we wrote the practitioner's guide to governing AI agents in procurement. It covers why the data model underneath decides how well your agents perform, and where MCP fits once agents start working with the rest of the business.
Get the free guideYour suppliers never see your P2P workflow. They see the PO.
A missing Incoterm or revision number is how a clean requisition turns into a disputed invoice. Our free Purchase Order Form Checklist lets you audit the PO you send suppliers against 16 fields, from PO number to Incoterms.
Download the free checklist
See you next week {{FIRST_NAME|readers}},
— The Pure Procurement Newsletter Team