MCP for Manufacturers: A Practical Guide

What is MCP, in plain terms?

The Model Context Protocol is a standard way for an AI assistant to call someone else's system and get back a typed, structured answer.

Anthropic open-sourced it on 25 November 2024, describing it as "a new standard for connecting AI assistants to the systems where data lives". On 9 December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI and backed at platinum level by AWS, Bloomberg, Cloudflare, Google and Microsoft. By that point MCP had passed 97 million monthly SDK downloads and more than 10,000 published servers, with first-class client support in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and VS Code.

For a non-developer decision-maker, the distinction that matters is this. When an assistant reads your website, it is interpreting a document: it can misread a table, miss a footnote, or blend two variants. When an assistant calls your MCP server, it is querying a system: it asks for the part, receives the fields, and reports them. The first mode produces plausible answers. The second produces correct ones — provided the data behind it is correct, which is where most of the real work sits.

Who has already shipped one in this industry?

This is no longer speculative, and the examples are usefully varied:

• Microchip Technology launched a free, public MCP server on 6 November 2025, exposing verified product specifications, datasheets, inventory, pricing and lead times over MCP Streamable HTTP, with JSON-encoded responses aimed at copilots, chatbots and enterprise agents.
• Siemens runs a public server at mcp.siemens.com whose documented plugins — assets, developer portal, search and web content — are available without authentication.
• Zoovu launched an MCP server on 11 December 2025 giving agents governed access to product data, positioned around accuracy on compatibility and application questions.
• ECIA launched the TrustedParts.com Inventory AI Agent Service on 11 June 2026, making authorised electronic component inventory available inside Microsoft Copilot, ChatGPT and Claude.
• Shopify exposes a Storefront MCP server on stores at https://{shop}.myshopify.com/api/mcp, with tools including search_catalog, lookup_catalog and get_product, and no authentication required for the storefront tier.

Two patterns are worth noting. Every one of these sits on top of an existing authoritative data store. And every one of them draws a line between public catalog data and anything commercially sensitive.

Tools or resources — which should a parts server use?

The specification is explicit about the difference, and getting it wrong produces a server models use badly.

Tools are model-controlled. The spec states that tools "are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." Discovery is tools/list; invocation is tools/call. Each tool carries an inputSchema (JSON Schema 2020-12 by default), an optional outputSchema, and returns structuredContent conforming to that schema.

Resources are application-driven. The spec states resources "are designed to be application-driven, with host applications determining how to incorporate context based on their needs" — typically a picker, a list, or automatic inclusion by the host. Each resource is identified by a URI, and templates allow parameterised URIs.

A catalog is a query space, not a fixed document set. Nobody wants to scroll a resource picker containing 40,000 parts. So the bulk of a parts server should be tools, with two refinements: use resource_link content blocks to point at datasheets and CAD files rather than inlining large payloads, and reserve genuine resources for a handful of stable documents such as a classification dictionary or a change log.

Two details from the current spec repay attention. Tool lists must not vary per connection, but may vary by the authorisation presented on the request. And servers should return tools in a deterministic order, because stable ordering lets clients cache the list and improves prompt-cache hit rates.

What changed in the 2026-07-28 specification?

This revision reshaped the transport, and any design written against 2025 material will be wrong in specific ways.

The transport shape is now pleasingly boring. The server exposes a single MCP endpoint accepting POST — for example https://example.com/mcp. Each JSON-RPC request is its own POST. Clients must send an Accept header listing both application/json and text/event-stream, plus an MCP-Protocol-Version header that must match the value in the body's _meta or the server must reject with 400 and a HeaderMismatch error. Servers must validate the Origin header and respond 403 if it is present and invalid.

The practical consequence for infrastructure teams: because there is no protocol-level session, your MCP server deploys behind a plain round-robin load balancer like any other stateless HTTP service. Roots, Sampling and Logging are now deprecated with a minimum twelve-month window, and the old HTTP+SSE transport is formally deprecated too.

How do you gate price and stock with OAuth?

Authorisation is optional in MCP, which is exactly right for a parts server: the public catalog should need no token at all, and only commercially sensitive tools should challenge.

When you do implement it, the requirements are specific. The MCP server acts as an OAuth 2.1 resource server, following the OAuth 2.1 IETF draft. It must implement Protected Resource Metadata (RFC 9728), and clients must use that metadata for authorisation-server discovery. Clients must implement Resource Indicators (RFC 8707), sending a resource parameter identifying your canonical server URI in both authorisation and token requests, and your server must validate that tokens were issued for it as the intended audience. Authorisation servers should return the iss parameter per RFC 9207 and clients must validate it. Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents, though it remains available for backwards compatibility.

The pattern that works for a distributor or manufacturer:

1. 01Unauthenticated tier — specifications, parametric search, alternates, compliance documents, CAD links, list prices where you publish them.
2. 02Authenticated tier — contract pricing, customer-specific availability, quote creation. Challenge with a 403 and error="insufficient_scope", naming the scopes needed so the client can step up in one round trip rather than several.
3. 03Never put a customer identifier in a tool argument as the only access control. A handle is a name, not a capability; validate authorisation on every call.

What should a parts MCP server expose?

Six to eight tools is the right order of magnitude. More than that and model selection degrades.

A tool definition should look unremarkable, and that is the point:

{
  "name": "search_parts",
  "title": "Parametric part search",
  "description": "Search the catalog by product class and typed parameter constraints. Returns matching parts with their key parametrics, units and last-verified date. Use get_part for the full record.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product_class": { "type": "string", "description": "ETIM class code or class name" },
      "constraints": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "parameter": { "type": "string" },
            "operator": { "type": "string", "enum": ["eq", "gte", "lte", "between", "in"] },
            "value": {},
            "unit": { "type": "string" }
          },
          "required": ["parameter", "operator", "value"]
        }
      },
      "limit": { "type": "integer", "default": 20 }
    },
    "required": ["product_class"],
    "additionalProperties": false
  }
}

Note what the description does: it tells the model what the tool returns and when to reach for a different tool. That single habit does more for answer quality than any amount of schema polish.

A worked example

A design engineer at a contract manufacturer in Texas is replacing an end-of-life part in a board that also ships to a German panel builder. The assistant has the manufacturer's MCP server connected.

Engineer: The 60 V N-channel MOSFET in our buck stage is going end-of-life. I need a drop-in in the same package, R_DS(on) no worse than 12 milliohms at 10 V gate drive, and I need to know if it is actually available.

The assistant makes four calls.

→ tools/call  get_part
   { "part_number": "XYZ-60N12-D2PAK" }
← structuredContent
   { "package": "D2PAK", "vds_v": 60, "rds_on_mohm": 11.5,
     "vgs_meas_v": 10, "lifecycle": "EOL", "last_verified": "2026-08-04" }

→ tools/call  find_alternates
   { "part_number": "XYZ-60N12-D2PAK", "basis": "form_fit_function" }
← structuredContent
   [ { "part_number": "XYZ-60N10-D2PAK", "equivalence": "drop-in",
       "rds_on_mohm": 9.8, "differences": ["lower R_DS(on)", "higher Qg"] },
     { "part_number": "XYZ-60N14-D2PAK", "equivalence": "footprint",
       "rds_on_mohm": 13.5, "differences": ["exceeds R_DS(on) limit"] } ]

→ tools/call  get_availability
   { "part_numbers": ["XYZ-60N10-D2PAK"] }
← 403 Forbidden
   WWW-Authenticate: Bearer error="insufficient_scope",
     scope="stock:read", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

   [client performs step-up authorisation, then retries]

← structuredContent
   { "part_number": "XYZ-60N10-D2PAK",
     "stock": [ { "location": "US-TX", "qty": 14200 },
                { "location": "DE-BW", "qty": 3800 } ],
     "lead_time_weeks": 8, "as_of": "2026-08-09T06:12:00Z" }

→ tools/call  get_compliance_documents
   { "part_number": "XYZ-60N10-D2PAK", "types": ["rohs", "reach"] }
← content: [ { "type": "resource_link", "uri": "https://…/rohs-2026-03.pdf",
               "name": "RoHS declaration (issued 2026-03-11)" } ]

The assistant then answers: one candidate is a drop-in with better on-resistance and higher gate charge, worth checking against the gate driver; the second clears the footprint but misses the R_DS(on) limit; stock is 14,200 in Texas and 3,800 in Baden-Württemberg as of this morning, on an eight-week lead time; RoHS and REACH declarations are attached with their issue dates.

Nothing here is impressive as engineering. It is impressive as commerce. Three sourcing decisions were made without a human opening a browser, and every figure is traceable to a timestamped record.

Who can actually reach your server today?

Be honest with your board about this, because the answer is narrower than most vendor material implies.

So MCP reaches engineers with an assistant they configure and enterprise buyers whose IT function registers your server. That is a small population by web standards and a very large one by pipeline standards.

How do agents discover your server?

There is no DNS-level discovery. Three mechanisms exist:

1. 01The official MCP registry at registry.modelcontextprotocol.io, the centralised metadata repository for publicly accessible servers, backed by Anthropic, GitHub, Microsoft and PulseMCP. It is open source, supports sub-registries, and remains in preview ahead of general availability — so expect churn.
2. 02Client-side directories, such as Claude's connectors directory and ChatGPT's app directory, each with their own review process.
3. 03Your own documentation. Today this is how most connections actually happen: a developer page states the endpoint URL, the tool list and the authorisation scopes, and a customer pastes it into their client.

Publish your .well-known/oauth-protected-resource document even if most tools are public, and version the endpoint path. You will change your tool surface, and you want that to be a deliberate migration rather than a silent break.

An implementation checklist

1. 01Resolve to one canonical record per part with typed attributes, units, provenance and a last-verified timestamp. Do not start with the protocol.
2. 02Pick six to eight tools and write descriptions that say when not to use each one.
3. 03Declare output schemas and return structuredContent. Include units and verification dates in every payload.
4. 04Serve a single POST endpoint with Mcp-Method and Mcp-Name headers honoured, Origin validated, and ttlMs and cacheScope set on list results.
5. 05Split public and gated tools, implement RFC 9728 metadata, validate token audience per RFC 8707, and use scope challenges to step up in one round trip.
6. 06Return deterministic tool ordering and stable tool names so client caches work.
7. 07Log every call — tool, arguments, latency, and whether the lookup resolved. An MCP server without analytics is a channel you cannot manage.
8. 08Monitor accuracy against ground truth, continuously. A tool that confidently returns a stale rating is worse than no tool.

Partsgraph provides this as a managed layer: we resolve your existing catalog into one verified Parts Graph, host the MCP endpoint with OAuth on the gated tiers, and report which agents called what and where the answers were wrong.

If you want to know where you stand before writing any code, run your domain through the free grader at /audit — it checks what machines can currently reach in your catalog, and whether an MCP endpoint would have anything trustworthy to serve.