# MCP for Manufacturers: A Practical Guide

> What the Model Context Protocol is, what a parts MCP server should expose, how OAuth gates price and stock, and which assistants can actually reach it.

**Published:** 2026-08-09  
**Category:** Technical · **Tags:** MCP, Model Context Protocol, OAuth, Streamable HTTP, parts data, AI agents  
**Canonical:** https://partsgraph.ai/blog/mcp-for-manufacturers

## In short

**What is MCP, and what should a manufacturer's MCP server expose?**

MCP (the Model Context Protocol) is an open standard that lets an AI assistant call your systems directly instead of inferring answers from your web pages. A manufacturer's MCP server is a hosted HTTP endpoint exposing a small set of typed tools — parametric search, part lookup, alternates and cross-references, compliance documents, CAD links, and OAuth-gated stock and pricing — which any compatible assistant can invoke to get an exact, auditable answer. Under the current 2026-07-28 specification it is a stateless request/response service that runs behind an ordinary load balancer. The protocol is the easy part; the hard part is having one canonical, verified product record behind it.

---

## 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.

| Change | Before | From 2026-07-28 |
| --- | --- | --- |
| Sessions | `Mcp-Session-Id` header, server-assigned | Removed; state passed as explicit server-minted handles in tool arguments |
| Handshake | `initialize` / `notifications/initialized` | Removed; protocol version and client capabilities travel in `_meta` on every request |
| Capability discovery | Learned at initialise | New `server/discover` RPC that servers **must** implement |
| Server-initiated requests | Sent on an SSE stream | Multi Round-Trip Requests: server returns `resultType: "input_required"`, client retries with `inputResponses` |
| Routing | Gateways parsed the JSON body | `Mcp-Method` and `Mcp-Name` headers **required** on POSTs |
| Caching | `listChanged` notifications only | `ttlMs` and `cacheScope` required on list and read results |
| Stream resumption | `Last-Event-ID` replay | Removed; a broken stream loses the request and the client re-issues it |

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. **Unauthenticated tier** — specifications, parametric search, alternates, compliance documents, CAD links, list prices where you publish them.
2. **Authenticated 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. **Never** 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.

| Tool | Purpose | Auth |
| --- | --- | --- |
| `search_parts` | Parametric search across a class with typed constraints and units | Public |
| `get_part` | Full canonical record for one part number, including provenance and last-verified date | Public |
| `find_alternates` | Functional equivalents, second sources and competitor cross-references, with a stated equivalence basis | Public |
| `get_compliance_documents` | RoHS, REACH, declarations of performance, certificates, EPDs — as records with issue dates, not just links | Public |
| `get_cad_models` | Resource links to 2D, 3D and BIM assets by format | Public |
| `get_availability` | Live stock by location and lead time | Gated |
| `get_price` | Customer contract pricing at quantity | Gated |

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

```json
{
  "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.

```text
→ 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.

| Client | Can it reach a custom MCP server? | Conditions |
| --- | --- | --- |
| Claude | Yes | Custom remote connectors on Free, Pro, Max, Team and Enterprise; free users limited to one; server must be reachable over the public internet from Anthropic's IP ranges |
| ChatGPT | Partly | Custom MCP servers via developer mode; write-capable connectors limited to Business, Enterprise and Edu, with Plus and Pro read-only. Apps in ChatGPT are built on MCP and go through directory review |
| Gemini | Enterprise only | Custom MCP servers registered by an administrator as a data store in Gemini Enterprise; Streamable HTTP transport only |
| Microsoft Copilot | Yes, in enterprise configurations | Administrator-registered connectors |
| IDE and CLI agents | Yes | Developer configures the endpoint directly — the lowest-friction path for engineering audiences |
| Your customers' own agents | Yes | Procurement and engineering teams increasingly run internal agents; this is the fastest-growing caller in practice |

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. **The 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. **Client-side directories**, such as Claude's connectors directory and ChatGPT's app directory, each with their own review process.
3. **Your 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. **Resolve to one canonical record per part** with typed attributes, units, provenance and a last-verified timestamp. Do not start with the protocol.
2. **Pick six to eight tools** and write descriptions that say when *not* to use each one.
3. **Declare output schemas** and return `structuredContent`. Include units and verification dates in every payload.
4. **Serve a single POST endpoint** with `Mcp-Method` and `Mcp-Name` headers honoured, `Origin` validated, and `ttlMs` and `cacheScope` set on list results.
5. **Split 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. **Return deterministic tool ordering** and stable tool names so client caches work.
7. **Log every call** — tool, arguments, latency, and whether the lookup resolved. An MCP server without analytics is a channel you cannot manage.
8. **Monitor 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](/audit) — it checks what machines can currently reach in your catalog, and whether an MCP endpoint would have anything trustworthy to serve.

## Common questions

### Do we need MCP if we already have a REST API?

Your REST API is the right foundation, but an agent cannot use it without bespoke integration work by whoever operates the agent. MCP standardises three things a REST API leaves open: how a client discovers what operations exist, how their inputs and outputs are typed for a model, and how authorisation is negotiated. In practice a parts MCP server is a thin, opinionated projection of an existing API with schemas and descriptions written for a model rather than a developer.

### Should parts data be exposed as tools or as resources?

Mostly tools. The specification describes tools as model-controlled — the model discovers and invokes them from context — while resources are application-driven, surfaced by the host application for a user to select. A catalog is a query space, not a fixed file list, so the natural fit is tools that take parameters. Resources earn their place for a small number of stable documents, and tools can return resource links to datasheets and CAD files rather than inlining megabytes.

### Does the 2026-07-28 specification break existing MCP servers?

It changes the shape of the transport significantly. Protocol-level sessions and the Mcp-Session-Id header are gone, the initialize handshake is gone, the standalone GET stream is gone, and SSE resumability via Last-Event-ID is gone. Servers must implement server/discover and require the Mcp-Method and Mcp-Name headers on POSTs. Clients supporting both eras detect which one a server speaks by attempting a modern request first and inspecting the error body before falling back.

### How do we stop an agent seeing another customer's pricing?

Use the authorisation layer rather than obscurity. The MCP server acts as an OAuth 2.1 resource server, must implement Protected Resource Metadata (RFC 9728), and must validate that access tokens were issued specifically for it as the intended audience per RFC 8707. Crucially, the specification allows the visible tool and resource sets to vary by the authorisation presented on the request, so an unauthenticated caller can be shown only the public catalog tools.

### How does an agent find our MCP server in the first place?

There is no DNS-level discovery mechanism, and pretending otherwise is the most common error in MCP writing. Discovery happens through the official MCP registry at registry.modelcontextprotocol.io, which is backed by Anthropic, GitHub, Microsoft and PulseMCP and remains in preview ahead of general availability; through client-side directories such as Claude's connectors directory and ChatGPT's app directory; and, most commonly today, because you published the URL in your developer documentation and a customer pasted it in.

### What is the biggest design mistake in a first parts MCP server?

Exposing too many tools with vague descriptions. A model chooses tools from their names, descriptions and schemas, so twenty overlapping search endpoints produce worse behaviour than six well-named ones. Return structured content against a declared output schema, keep tool names deterministic and stable, and put units, tolerances and a last-verified timestamp in the payload so the answer can be audited later.

### Does an MCP server help with AI visibility on the open web?

Not directly. Search and retrieval crawlers do not call MCP servers; they fetch HTML. MCP reaches users who have connected your server, which today means engineers configuring a connector and enterprise buyers whose administrator registers it. It is a depth channel, not a reach channel, and it works best alongside server-rendered, structured product pages.

## Sources

1. [Anthropic, Introducing the Model Context Protocol (25 November 2024)](https://www.anthropic.com/news/model-context-protocol)
2. [Model Context Protocol, MCP joins the Agentic AI Foundation (9 December 2025)](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/)
3. [Linux Foundation, Formation of the Agentic AI Foundation (9 December 2025)](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
4. [Model Context Protocol, 2026-07-28 specification changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
5. [Model Context Protocol, Streamable HTTP transport (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)
6. [Model Context Protocol, Authorization (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
7. [Model Context Protocol, Tools (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
8. [Model Context Protocol, Resources (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/resources)
9. [Model Context Protocol, The MCP Registry](https://modelcontextprotocol.io/registry/about)
10. [Microchip Technology, Microchip unveils Model Context Protocol (MCP) Server (6 November 2025)](https://ir.microchip.com/news-events/press-releases/detail/1344/microchip-technology-unveils-model-context-protocol-mcp-server-to-power-ai-driven-product-data-access)
11. [Siemens MCP Server documentation](https://mcp.siemens.com/docs)
12. [Zoovu, Zoovu launches MCP Server (11 December 2025)](https://zoovu.com/news/zoovu-launches-mcp-server)
13. [ECIA, TrustedParts.com launches Inventory AI Agent Service (11 June 2026)](https://www.ecianow.org/2026/06/11/trustedparts-com-launches-inventory-ai-agent-service/)
14. [Shopify, Storefront MCP server documentation](https://shopify.dev/docs/apps/build/storefront-mcp/servers/storefront)
15. [Anthropic, Get started with custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)
16. [OpenAI Help Center, Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt)
17. [Google Cloud, Set up your custom MCP server data store (Gemini Enterprise)](https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server)

---

Partsgraph — the agent-ready parts data layer. Free AI-visibility grader: https://partsgraph.ai/audit