What is an MCP server, explained for hardware teams

If you work in hardware, you’ve probably seen “MCP server” appear in vendor pitches sometime in the last year and wondered whether it’s a real architectural idea or this cycle’s rebranding of “API”. Short answer: it’s real, it’s simple, and it matters more for hardware teams than for most — because nobody’s data is more fragmented across systems than ours. Here’s the whole concept, no mysticism.

The protocol, in one paragraph

MCP — Model Context Protocol — is an open standard (introduced by Anthropic in late 2024, since adopted broadly) that defines how an AI model talks to external systems. An MCP server is a program that exposes a set of tools — typed, named functions like get_work_order(wo_id) or find_pos_by_part(part, rev) — plus their descriptions and schemas. An MCP client (Claude, Claude Code, and a growing list of agents and IDEs) connects to the server, reads the tool list, and lets the model call those tools during a conversation. That’s it. It is JSON-RPC with a discovery mechanism, standardized so that any client can use any server without custom glue.

The useful mental model for an engineer: MCP is to AI agents what USB was to peripherals. Before USB, every device needed its own port and driver. Before MCP, every AI integration was a custom build against one model vendor’s function-calling format. After: one connector shape, and the ecosystem composes.

What an MCP server is not

Because the term gets thrown around loosely, it’s worth drawing the boundaries:

It’s not an API wrapper for humans. You don’t call MCP tools yourself; the model does, mid-conversation, deciding which tools to use based on your question. The tool descriptions are written for the model to read.
It’s not a data pipeline. An MCP server moves nothing on a schedule. It sits idle until a question arrives, reads what’s needed to answer, and returns it. There is no destination database, no mapping table, no nightly job.
It’s not the model. The server has no intelligence; it’s deliberately dumb plumbing. All reasoning — which tools to call, in what order, how to combine results — happens in the client-side model. This separation is what makes the security story tractable, as we’ll get to.

Why this matters specifically for hardware teams

Software companies mostly have their operational data in a couple of SaaS tools with decent search. Hardware companies run a stack: PLM for design truth (Duro, Arena), MES or factory software for execution (ION Factory OS), ERP or accounting for money (NetSuite, Xero, Odoo), often test and operations tooling on top (Epsilon3). Each is the correct system for its job. None of them can answer a question that spans two of them.

And the expensive questions always span two of them:

“Which open POs are affected by this ECO?” — PLM + procurement.
“Do we have enough spares to survive another test failure like yesterday’s?” — test records + inventory.
“Has the supplier blocking WO-88 been paid?” — MES + accounting.

The traditional answer is point-to-point integration: sync system A into system B, or both into a warehouse. That’s an O(n²) problem — every pair needs its own connector, mapping and maintenance — and hardware data models make it worse, because revisions and effectivity don’t survive flattening into generic records. (We wrote about the canonical failure, ECO-to-PO drift, separately.)

MCP restructures the problem. Each system gets one MCP server — an adapter written once, exposing that system’s concepts as tools. The cross-system joining that used to require a connector per pair now happens in the agent’s reasoning at question time. Add an nth system and you’ve added one server, not n-1 integrations. The O(n²) connector matrix becomes O(n) adapters plus a model that can read.

Concretely, that’s how a question like the ECO one gets answered: the agent calls get_eco("ECO-142") on the PLM server, sees which part revisions changed, calls find_pos_by_part("PN-1042", rev="C") on the factory server, then get_bill_status(...) on the accounting server — three servers, one conversation, sources cited. Pages like ION + Xero or Duro + NetSuite show what this looks like pairing by pairing.

”So it’s function calling. Why the protocol?”

Fair question — models could call APIs before MCP. Three things changed:

Portability. A function-calling integration is welded to one vendor’s format and usually one application. An MCP server works with every MCP client — Claude today, your internal agent tomorrow — without modification. The integration outlives the app it was built for.
Discovery. Clients enumerate a server’s tools and schemas at connect time. Adding a tool to the server makes it available everywhere immediately; there’s no client-side deployment step.
An operational boundary. Because every model-to-system interaction passes through one protocol layer, that layer is where you enforce policy: which tools exist, what scopes they run under, what gets logged. That’s a much better place for governance than “each engineer’s scripts do their own auth.”

The security model, since agents touching production systems should scare you

The right instinct about “AI can query our ERP” is caution. The architecture is what makes it defensible, and it’s worth knowing what to insist on regardless of whose server you use:

Read-only by default. Tools that only read cannot be talked into writing. Write operations, where they exist at all, should be separate tools behind explicit human approval per action.
Scoped credentials. The server holds one properly-scoped OAuth grant or service role per system — not a copy of anyone’s admin API key, and users never handle credentials at all.
Complete audit. Every call — who asked, which tool, what arguments, what was returned — logged and exportable. For AS9100/ISO-audited shops, this makes the AI a documented interface, which puts it ahead of the CSV exports it replaces. Those never had an access log.
Deployment control. For export-controlled (ITAR) data, a multitenant cloud is a non-starter no matter how good the policy is; the server has to run inside your perimeter. This is a deployment question, not a protocol limitation — MCP works the same self-hosted.

That posture is roughly the whole thesis behind how we built bomrail.

Hosted vs. self-built

You can write an MCP server in an afternoon — the SDKs are good, and for one internal tool you should try it; it demystifies the whole thing. The build-vs-buy line shows up where it always does: per-system API auth lifecycles, rate limiting, schema drift when your PLM vendor ships an update, audit logging users trust, and doing all of it n times for n systems. That undifferentiated middle is what a hosted product like bomrail exists to own — one endpoint for ION, Duro, Xero and the rest of your stack, with the security posture above as the default.

However you get there, the direction is settled: your engineering systems are becoming things you ask, not just things you log into. The protocol is the boring part. What it unlocks — the digital thread as a conversation — is not.