How to let an AI agent buy industrial supplies (with MCP)

The wall every buying agent hits

Give a capable agent a job like "our facility is low on nitrile gloves and 2-inch packing tape, get them ordered" and it does the first 80 percent well. It identifies the products, checks a spec, maybe compares a couple of listings. Then it needs to actually transact with a supplier, and the supplier is a distributor whose quoting process is an inside-sales rep reading email. There is no endpoint. The agent can draft a purchase order into a document, but it cannot get a real, priced, sourced quote back from a business that will fulfill it.

That gap is the whole problem. Everything upstream of "get a quote from a real supplier" is solved; the buy itself is not, because B2B distribution runs on email, phone, and portals built for humans clicking. An agent that has to fill out a web form is not really transacting; it is puppeteering a human interface.

What MCP changes

MCP, the Model Context Protocol, is a standard way for an agent to call external tools without a bespoke integration per service. A supplier that exposes an MCP server gives any MCP-capable agent a defined set of actions it can take: ask what the supplier carries, check whether a parts list is well-formed, and submit a request for quote. The agent speaks one protocol; the supplier does the sourcing and pricing on its side.

We run one, because we are a distributor and we wanted to answer machines as cleanly as we answer email. The endpoint is a remote Streamable HTTP server at https://www.cintrasupply.com/mcp. No authentication to start, and quotes are free. Point an MCP client at it and the agent sees four tools.

The four tools an agent gets

• get_supplier_capabilities — the categories we cover, the input formats we accept, and where quotes go. The agent calls this first so it knows whether a request belongs here before asking.
• validate_bom — checks a bill of materials of up to 500 lines for missing identifiers and ambiguous substitution instructions, and returns the problems line by line. This is the step that keeps a sloppy parts list from becoming a bad quote.
• prepare_quote_request — normalizes structured lines into our quote-ready format and returns a human review link. Preparing is not submitting.
• submit_quote_request — optionally submits a non-binding RFQ, after the user has explicitly confirmed. Our desk prices it and replies like any other request.

What it looks like in practice

Connecting is a few lines of config in any MCP client:

From there a typical agent flow is:

1. Call get_supplier_capabilities and confirm the request (say, safety and packaging items) is in scope.
2. Assemble the parts list it has been given or has researched, and call validate_bom. Fix anything flagged (a missing part number, an "or equivalent" with no permission set).
3. Call prepare_quote_request to get a formatted request and a review link.
4. Surface that to its user for confirmation, then call submit_quote_request. A human desk prices it and the quote comes back with each line sourced and evidenced.

If the buyer is a person supervising the agent, they get a normal quote and approve it. If the request came in through a maintenance platform or an ops agent, the same quote flows back through the same channel. One desk, two protocols: email for people, MCP for machines.

Where the human stays, on purpose

This is the part we are deliberate about, because "autonomous purchasing" is easy to oversell. The boundaries are enforced, not aspirational:

• Preparing is not submitting. A prepared request formats lines and returns a link. Nothing leaves until submission is explicitly confirmed.
• Submitting is not ordering. An RFQ does not place an order, reserve inventory, or create a binding price or delivery commitment. A written quote, approved by a person, is what commits.
• Exact match by default. The agent gets alternatives only if the request explicitly permits them, and any alternative comes back flagged as an alternative, never silently swapped.
• The review link is the reliable path. Direct submission stays off by default and is enabled and monitored per client.

The reason to build it this way is trust in both directions. A supplier that lets an agent commit money on the first call is a supplier that gets gamed. A buyer whose agent can silently order the wrong pump does not stay a buyer. Keeping a person on the approval of a commercial commitment is what makes the automation usable, not a limitation we are apologizing for.

Where this is going

The near-term roadmap is the rest of the loop over the same endpoint: quote retrieval, acceptance, and order tracking, so an agent can follow a request from submitted to delivered. Autonomous ordering with payment, inside envelopes a buyer sets, is the destination, and it arrives as the trust record accumulates, not as a switch we flip.

If you are building an agent that needs to buy real things, a maintenance or CMMS platform, a facilities or ops agent, a procurement copilot, the endpoint is live now and we are working with a small number of design partners on what comes next.