# メーカーのためのMCP実践ガイド

> Model Context Protocolとは何か。部品向けのMCPサーバーは何を公開すべきか。OAuthは価格と在庫をどのように保護するのか。そして、そのサーバーに実際に到達できるAIアシスタントはどれなのか。メーカー向けに、2026-07-28仕様に沿って設計と実装の要点を整理する。

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

## 要点

**MCPとは何か。そして、メーカーのMCPサーバーは何を公開すべきか**

MCP（Model Context Protocol）は、AIアシスタントがWebページから答えを推測するのではなく、企業のシステムを直接呼び出せるようにするオープンな標準規格である。メーカーのMCPサーバーとは、型付けされた少数のツール——パラメトリック検索、型番照会、代替品とクロスリファレンス、コンプライアンス文書、CADリンク、そしてOAuthで保護された在庫と価格——を公開するホスト型のHTTPエンドポイントであり、対応するアシスタントであればどれでも呼び出して、正確で監査可能な回答を得られる。現行の2026-07-28仕様では、これは通常のロードバランサーの背後で動作するステートレスなリクエスト／レスポンス型のサービスである。プロトコルは易しい部分にすぎない。難しいのは、その背後に唯一の正規かつ検証済みの製品レコードを用意することだ。

---

## MCPとは何か、平たく言えば

Model Context Protocolとは、AIアシスタントが他社のシステムを呼び出し、型付けされた構造化データとして回答を受け取るための、標準的な方法である。

Anthropicは2024年11月25日にこれをオープンソースとして公開し、「AIアシスタントを、データが存在するシステムに接続するための新しい標準規格」と説明した。2025年12月9日、AnthropicはMCPをAgentic AI Foundationへ寄贈した。これはLinux Foundation傘下の指定基金で、BlockおよびOpenAIと共同で設立され、AWS、Bloomberg、Cloudflare、Google、Microsoftがプラチナ級で支援している。その時点でMCPは、SDKの月間ダウンロード数9,700万件、公開サーバー数1万件超を突破しており、ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS Codeが一級のクライアントサポートを提供していた。

> **Figure.** Parsing forty pages versus one typed MCP tool call.

開発者ではない意思決定者にとって重要な区別は、次の点にある。アシスタントが自社のWebサイトを読むとき、それは*文書を解釈している*。表を読み違えることも、脚注を見落とすことも、二つの派生品を混同することもある。アシスタントが自社のMCPサーバーを呼び出すとき、それは*システムに問い合わせている*。部品を指定して要求し、フィールドを受け取り、それをそのまま報告する。前者のやり方はもっともらしい答えを生む。後者は正しい答えを生む——ただし、その背後にあるデータが正しければの話であり、実際の作業の大半はそこに存在する。

## この業界で、すでに公開しているのは誰か

これはもはや机上の話ではなく、事例も参考になる程度に多様である。

- **Microchip Technology**は2025年11月6日、無償かつ公開のMCPサーバーを立ち上げた。検証済みの製品仕様、データシート、在庫、価格、リードタイムをMCPのStreamable HTTP経由で公開し、コパイロット、チャットボット、企業向けエージェントを想定したJSON形式のレスポンスを返す。
- **Siemens**は`mcp.siemens.com`で公開サーバーを運用しており、ドキュメント化されたプラグイン——アセット、開発者ポータル、検索、Webコンテンツ——を認証なしで利用できる。
- **Zoovu**は2025年12月11日にMCPサーバーを公開し、統制された製品データへのアクセスをエージェントに提供している。互換性や用途に関する問い合わせでの正確性を訴求点としている。
- **ECIA**は2026年6月11日にTrustedParts.comのInventory AI Agent Serviceを開始し、正規流通の電子部品在庫をMicrosoft Copilot、ChatGPT、Claudeの中から参照できるようにした。
- **Shopify**は各ストアの`https://{shop}.myshopify.com/api/mcp`でStorefront MCPサーバーを公開している。ツールには`search_catalog`、`lookup_catalog`、`get_product`などがあり、ストアフロント層では認証を必要としない。

注目すべき共通点が二つある。いずれも、既存の権威あるデータストアの上に載っていること。そしていずれも、公開カタログデータと、商業的に機微な情報とのあいだに線を引いていることだ。

## ツールかリソースか——部品サーバーはどちらを使うべきか

仕様は両者の違いを明確に定めており、ここを取り違えると、モデルがうまく使えないサーバーができあがる。

**ツールはモデル制御である。** 仕様は、ツールは「**モデル制御**であるように設計されており、言語モデルが文脈の理解とユーザーのプロンプトに基づいて、自動的にツールを発見し呼び出せることを意味する」と述べている。発見は`tools/list`、呼び出しは`tools/call`である。各ツールは`inputSchema`（既定ではJSON Schema 2020-12）と、任意で`outputSchema`を持ち、そのスキーマに準拠した`structuredContent`を返す。

**リソースはアプリケーション主導である。** 仕様は、リソースは「**アプリケーション主導**であるように設計されており、ホストアプリケーションが自らの必要に応じて、コンテキストの取り込み方を決定する」と述べている——典型的にはピッカー、一覧、あるいはホストによる自動的な取り込みという形をとる。各リソースはURIで識別され、テンプレートによってパラメーター付きのURIも扱える。

カタログはクエリ空間であって、固定された文書の集合ではない。4万点の部品が並ぶリソースピッカーをスクロールしたい人はいない。したがって部品サーバーの大半はツールで構成すべきであり、そこに二つの工夫を加える。大きなペイロードを埋め込むのではなく、`resource_link`コンテンツブロックでデータシートやCADファイルを指し示すこと。そして、真の意味でのリソースは、分類辞書や変更履歴といった、数の限られた安定した文書のために取っておくことだ。

現行仕様の細部のうち、注意を払う価値のあるものが二つある。ツール一覧は接続ごとに変化**してはならない**が、リクエストで提示された認可に応じて変化**してもよい**。また、サーバーはツールを決定的な順序で返す**べきである**。順序が安定していればクライアントは一覧をキャッシュでき、プロンプトキャッシュのヒット率も上がるからだ。

## 2026-07-28仕様で何が変わったのか

この改訂はトランスポートの形を作り変えた。2025年の資料をもとに書かれた設計は、いくつかの具体的な点で誤りになる。

| 変更点 | 従来 | 2026-07-28以降 |
| --- | --- | --- |
| セッション | サーバーが割り当てる`Mcp-Session-Id`ヘッダー | 廃止。状態は、サーバーが発行する明示的なハンドルとしてツール引数で受け渡す |
| ハンドシェイク | `initialize`／`notifications/initialized` | 廃止。プロトコルバージョンとクライアント機能は、毎回のリクエストの`_meta`で送る |
| 機能の発見 | 初期化時に把握 | 新設の`server/discover` RPC。サーバーは実装し**なければならない** |
| サーバー起点のリクエスト | SSEストリームで送信 | Multi Round-Trip Requests。サーバーが`resultType: "input_required"`を返し、クライアントが`inputResponses`を添えて再試行する |
| ルーティング | ゲートウェイがJSONボディを解析していた | POSTには`Mcp-Method`と`Mcp-Name`ヘッダーが**必須** |
| キャッシュ | `listChanged`通知のみ | 一覧および読み取りの結果に`ttlMs`と`cacheScope`が必須 |
| ストリームの再開 | `Last-Event-ID`による再送 | 廃止。ストリームが切れればリクエストは失われ、クライアントが出し直す |

トランスポートの形は、いまや心地よいほど退屈なものになった。サーバーはPOSTを受け付ける単一のMCPエンドポイント——たとえば`https://example.com/mcp`——を公開する。JSON-RPCのリクエストは、それぞれが独立したPOSTである。クライアントは`application/json`と`text/event-stream`の両方を列挙した`Accept`ヘッダーに加えて、`MCP-Protocol-Version`ヘッダーを送らなければならない。その値はボディの`_meta`の値と一致していなければならず、一致しなければサーバーは400と`HeaderMismatch`エラーで拒否しなければならない。サーバーは`Origin`ヘッダーを検証し、それが存在していて不正な場合には403を返さなければならない。

インフラ担当チームにとっての実務上の帰結はこうだ。プロトコルレベルのセッションが存在しないため、MCPサーバーは、他のステートレスなHTTPサービスと同じように、素のラウンドロビン方式のロードバランサーの背後に配置できる。Roots、Sampling、Loggingは最低12か月の猶予期間を伴って非推奨となり、旧来のHTTP+SSEトランスポートも正式に非推奨となった。

## OAuthで価格と在庫をどう保護するか

MCPにおいて認可は**任意**である。これは部品サーバーにとって、まさに適切な設計だ。公開カタログにトークンは一切必要なく、商業的に機微なツールだけが認証を要求すればよい。

実際に実装する場合、要件は具体的である。MCPサーバーは、OAuth 2.1のIETFドラフトに従うOAuth 2.1リソースサーバーとして振る舞う。Protected Resource Metadata（RFC 9728）を実装し**なければならず**、クライアントは認可サーバーの発見にそのメタデータを使わ**なければならない**。クライアントはResource Indicators（RFC 8707）を実装し**なければならず**、認可リクエストとトークンリクエストの双方で、自社サーバーの正規URIを示す`resource`パラメーターを送る。そしてサーバー側は、トークンが自らを想定audienceとして発行されたものであることを検証し**なければならない**。認可サーバーはRFC 9207に従って`iss`パラメーターを返す**べきであり**、クライアントはそれを検証しなければならない。Dynamic Client Registrationは現在、Client ID Metadata Documentsに取って代わられて非推奨となったが、後方互換のために引き続き利用できる。

販売代理店やメーカーにとって有効なパターンは、次のとおりである。

1. **未認証の層**——仕様、パラメトリック検索、代替品、コンプライアンス文書、CADリンク、そして公開しているなら定価。
2. **認証済みの層**——契約価格、顧客ごとの在庫状況、見積作成。403と`error="insufficient_scope"`で認証を要求し、必要なスコープを明示する。そうすればクライアントは、何往復もせず一度の往復で権限を引き上げられる。
3. 顧客識別子をツール引数に入れ、それだけをアクセス制御とすることは**決してしてはならない**。ハンドルは名前であって権限ではない。認可は呼び出しのたびに検証すること。

## 部品向けMCPサーバーは何を公開すべきか

ツールは6〜8個というのが、妥当な規模感である。それを超えると、モデルによるツール選択の精度が落ちる。

| ツール | 用途 | 認証 |
| --- | --- | --- |
| `search_parts` | 型付けされた条件と単位による、製品クラス横断のパラメトリック検索 | 公開 |
| `get_part` | 単一型番の完全な正規レコード。出所と最終検証日を含む | 公開 |
| `find_alternates` | 機能的な同等品、セカンドソース、他社品のクロスリファレンス。同等性の判断根拠を明示 | 公開 |
| `get_compliance_documents` | RoHS、REACH、性能宣言、証明書、EPD——単なるリンクではなく、発行日を伴うレコードとして | 公開 |
| `get_cad_models` | 2D、3D、BIMのアセットへの、形式別のリソースリンク | 公開 |
| `get_availability` | 拠点別のリアルタイム在庫とリードタイム | 要認証 |
| `get_price` | 数量に応じた顧客の契約価格 | 要認証 |

ツールの定義は、取り立てて特別なものには見えないはずだ。そして、それこそが要点である。

```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
  }
}
```

この説明文が果たしている役割に注目してほしい。そのツールが何を返すかをモデルに伝え、*さらに*、どんなときに別のツールを使うべきかまで伝えている。この一つの習慣は、スキーマをどれだけ磨き上げるよりも、回答の品質に効く。

## 実例で追ってみる

テキサスにある受託製造メーカーの設計エンジニアが、ドイツの盤メーカーにも出荷している基板上で、生産終了になる部品を置き換えようとしている。アシスタントには、そのメーカーのMCPサーバーが接続されている。

> **エンジニア:** 降圧段に使っている60 VのNチャネルMOSFETが生産終了になる。同じパッケージでそのまま置き換えられる品種で、ゲート駆動10 VでのR_DS(on)が12ミリオーム以下のものがほしい。それと、本当に入手できるのかどうかも知りたい。

アシスタントは4回の呼び出しを行う。

```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)" } ]
```

そのうえでアシスタントはこう答える。候補の一つはそのまま置き換えられる品種で、オン抵抗はより低く、ゲート電荷はより大きいので、ゲートドライバーとの整合を確認する価値がある。二つ目はフットプリントは合うが、R_DS(on)の上限を満たさない。在庫は今朝の時点でテキサスに14,200個、バーデン＝ヴュルテンベルクに3,800個、リードタイムは8週間。RoHSとREACHの宣言書は、発行日とともに添付されている。

ここに書かれていることは、エンジニアリングとしては何ら目を見張るものではない。目を見張るのは*商取引*としてである。三つの調達判断が、人間が一度もブラウザを開くことなく下され、しかもすべての数値が、タイムスタンプ付きのレコードまで遡って確認できる。

## いま実際に自社サーバーへ到達できるのは誰か

この点は取締役会に正直に伝えたほうがよい。答えは、ベンダー資料の多くがほのめかしているよりも、ずっと狭いからだ。

| クライアント | 独自のMCPサーバーに到達できるか | 条件 |
| --- | --- | --- |
| Claude | できる | Free、Pro、Max、Team、Enterpriseでカスタムのリモートコネクターを利用可能。無料ユーザーは1件まで。サーバーはAnthropicのIPレンジから公開インターネット経由で到達できる必要がある |
| ChatGPT | 部分的に | 開発者モード経由で独自のMCPサーバーを利用可能。書き込み可能なコネクターはBusiness、Enterprise、Eduに限られ、PlusとProは読み取り専用。ChatGPT内のアプリはMCPの上に構築され、ディレクトリの審査を経る |
| Gemini | 法人向けのみ | 管理者がGemini Enterpriseのデータストアとして独自のMCPサーバーを登録する方式。トランスポートはStreamable HTTPのみ |
| Microsoft Copilot | できる（法人向け構成で） | 管理者が登録したコネクター |
| IDEおよびCLIのエージェント | できる | 開発者がエンドポイントを直接設定する——技術者層に対して、最も摩擦の少ない経路 |
| 顧客自身のエージェント | できる | 調達部門や技術部門が社内エージェントを運用する例が増えている。実務上、最も急速に伸びている呼び出し元である |

つまりMCPが届くのは、自分でアシスタントを設定するエンジニアと、情報システム部門が自社サーバーを登録した法人の購買担当者である。Webの尺度で見れば小さな母数だが、営業パイプラインの尺度で見れば、きわめて大きな母数だ。

## エージェントはどうやってサーバーを見つけるのか

DNSレベルの発見手段は存在しない。仕組みは三つある。

1. **公式のMCPレジストリ**。`registry.modelcontextprotocol.io`にあり、一般公開されたサーバーのメタデータを集約する中央リポジトリで、Anthropic、GitHub、Microsoft、PulseMCPが支援している。オープンソースであり、サブレジストリにも対応しているが、一般提供に向けたプレビュー段階にとどまっている——つまり、まだ変動が続くと見ておくべきだ。
2. **クライアント側のディレクトリ**。Claudeのコネクターディレクトリや、ChatGPTのアプリディレクトリなどで、それぞれ独自の審査プロセスを持つ。
3. **自社のドキュメント。** 今日、実際の接続の大半はこの経路で生まれている。開発者向けページにエンドポイントのURL、ツール一覧、認可スコープを記載し、顧客がそれを自分のクライアントに貼り付ける、というものだ。

ツールの大半が公開のものであっても、`.well-known/oauth-protected-resource`のドキュメントは公開しておくこと。そして、エンドポイントのパスにはバージョンを付けること。ツールの構成はいずれ必ず変わる。そのときに起きるべきなのは、意図をもって進める移行であって、黙って壊れることではない。

## 実装チェックリスト

1. **部品ごとに唯一の正規レコードへ名寄せする。** 型付けされた属性、単位、出所、最終検証日時を備えたものにすること。プロトコルから着手してはならない。
2. **ツールを6〜8個に絞る。** そして、それぞれについて*使うべきでない*のはどんなときかを記した説明文を書く。
3. **出力スキーマを宣言し**、`structuredContent`を返す。単位と検証日は、すべてのペイロードに含めること。
4. **単一のPOSTエンドポイントを提供する。** `Mcp-Method`と`Mcp-Name`ヘッダーを尊重し、`Origin`を検証し、一覧の結果には`ttlMs`と`cacheScope`を設定する。
5. **公開ツールと要認証ツールを分ける。** RFC 9728のメタデータを実装し、RFC 8707に従ってトークンのaudienceを検証し、スコープの提示によって一度の往復で権限を引き上げられるようにする。
6. **ツールの順序を決定的に返し**、ツール名を安定させる。そうすればクライアント側のキャッシュが機能する。
7. **すべての呼び出しを記録する**——ツール、引数、レイテンシー、そして照会が解決したかどうか。分析のないMCPサーバーは、管理できないチャネルである。
8. **正解データと突き合わせて、精度を継続的に監視する。** 古い定格値を自信たっぷりに返すツールは、ツールがないよりも悪い。

Partsgraphは、これをマネージドなレイヤーとして提供している。既存のカタログを一つの検証済みParts Graphへと名寄せし、要認証層にOAuthを備えたMCPエンドポイントをホストし、どのエージェントが何を呼び出したのか、そしてどの回答が誤っていたのかを報告する。

コードを1行も書く前に自社の現在地を知りたいなら、[/audit](/audit)にある無料のグレーダーで自社ドメインを診断してほしい。いま機械が自社カタログの何に到達できているのか、そしてMCPエンドポイントを立てたとして、そこに信頼に足るものを載せられるのかが分かる。

## よくある質問

### すでにREST APIがあるなら、MCPは必要か

REST APIは土台として正しい。ただしエージェントは、それを運用する側が個別に統合作業を行わない限り、そのAPIを使えない。MCPは、REST APIが決めずに残している三つの事柄を標準化する。どんな操作が存在するかをクライアントがどう発見するか、その入出力をモデル向けにどう型付けするか、そして認可をどう取り決めるか、である。実務的に言えば、部品向けのMCPサーバーとは、既存のAPIを薄く、方針を持って射影したものであり、そのスキーマと説明文は、開発者ではなくモデルに向けて書かれている。

### 部品データはツールとして公開すべきか、リソースとして公開すべきか

大半はツールである。仕様はツールをモデル制御——モデルが文脈から発見し、自ら呼び出す——と位置づけ、リソースはアプリケーション主導で、ホストアプリケーションがユーザーに選ばせるために提示するものだとしている。カタログは固定されたファイル一覧ではなくクエリ空間であるから、パラメーターを受け取るツールのほうが自然に適合する。リソースが役割を持つのは、数の限られた安定した文書に対してである。データシートやCADファイルは、数メガバイトを埋め込むのではなく、ツールがリソースリンクを返せばよい。

### 2026-07-28仕様は、既存のMCPサーバーを壊すのか

トランスポートの形は大きく変わる。プロトコルレベルのセッションとMcp-Session-Idヘッダーは廃止され、initializeによるハンドシェイクも、単独のGETストリームも、Last-Event-IDによるSSEの再開機能も、いずれもなくなった。サーバーはserver/discoverを実装し、POSTにはMcp-MethodとMcp-Nameヘッダーを要求しなければならない。両方の世代に対応するクライアントは、まず新仕様のリクエストを試み、エラーボディを確認したうえで旧仕様へフォールバックすることで、相手のサーバーがどちらを話すのかを判定する。

### エージェントが他の顧客の価格を見てしまうのを、どう防ぐか

隠すことに頼るのではなく、認可の層で防ぐ。MCPサーバーはOAuth 2.1のリソースサーバーとして振る舞い、Protected Resource Metadata（RFC 9728）を実装しなければならず、アクセストークンが自らを想定audienceとして発行されたものであることを、RFC 8707に従って検証しなければならない。決定的に重要なのは、リクエストで提示された認可に応じて、見えるツールとリソースの集合を変えることを仕様が認めている点である。したがって、未認証の呼び出し元には、公開カタログ用のツールだけを見せることができる。

### そもそもエージェントは、どうやって自社のMCPサーバーを見つけるのか

DNSレベルの発見の仕組みは存在せず、あるかのように書くことは、MCPに関する文章で最もよくある誤りである。発見は次の経路で起こる。registry.modelcontextprotocol.ioにある公式のMCPレジストリ——Anthropic、GitHub、Microsoft、PulseMCPが支援しており、一般提供に向けたプレビュー段階にとどまっている。Claudeのコネクターディレクトリや、ChatGPTのアプリディレクトリといったクライアント側のディレクトリ。そして今日いちばん多いのは、自社の開発者向けドキュメントにURLを掲載し、顧客がそれを貼り付けた、という経路である。

### 最初の部品向けMCPサーバーで、最大の設計上の誤りは何か

曖昧な説明文のついたツールを、あまりに多く公開してしまうことだ。モデルはツールの名前、説明、スキーマからツールを選ぶ。だから、重複した検索エンドポイントが20個あるより、うまく命名された6個のほうが、はるかによい挙動になる。宣言した出力スキーマに沿って構造化データを返し、ツール名は決定的で安定したものに保ち、単位、公差、最終検証日時をペイロードに入れておくこと。そうすれば、あとから回答を監査できる。

### MCPサーバーは、オープンなWeb上でのAI可視性に役立つのか

直接には役立たない。検索や情報取得のクローラーはMCPサーバーを呼び出さない。取りに来るのはHTMLである。MCPが届くのは、自社サーバーを接続済みのユーザーだけであり、それは今日のところ、自らコネクターを設定するエンジニアと、管理者がそれを登録した法人の購買担当者を意味する。MCPは到達範囲を広げるチャネルではなく、深さのチャネルである。サーバーサイドでレンダリングされた構造化済みの製品ページと組み合わせたときに、最も効果を発揮する。

## 出典

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)

## Other languages

- English: https://partsgraph.ai/blog/mcp-for-manufacturers/md
- Deutsch: https://partsgraph.ai/de/blog/mcp-for-manufacturers/md
- Français: https://partsgraph.ai/fr/blog/mcp-for-manufacturers/md
- Español: https://partsgraph.ai/es/blog/mcp-for-manufacturers/md
- Italiano: https://partsgraph.ai/it/blog/mcp-for-manufacturers/md
- Nederlands: https://partsgraph.ai/nl/blog/mcp-for-manufacturers/md
- Polski: https://partsgraph.ai/pl/blog/mcp-for-manufacturers/md
- Português: https://partsgraph.ai/pt/blog/mcp-for-manufacturers/md
- Svenska: https://partsgraph.ai/sv/blog/mcp-for-manufacturers/md
- Türkçe: https://partsgraph.ai/tr/blog/mcp-for-manufacturers/md
- 한국어: https://partsgraph.ai/ko/blog/mcp-for-manufacturers/md
- 简体中文: https://partsgraph.ai/zh/blog/mcp-for-manufacturers/md

---

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