MCP för tillverkare: en praktisk guide

Vad är MCP, i klartext?

Model Context Protocol är ett standardiserat sätt för en AI-assistent att anropa någon annans system och få tillbaka ett typat, strukturerat svar.

Anthropic släppte det som öppen källkod den 25 november 2024 och beskrev det som ”en ny standard för att koppla AI-assistenter till de system där data finns”. Den 9 december 2025 donerade Anthropic MCP till Agentic AI Foundation, en riktad fond under Linux Foundation som grundades tillsammans med Block och OpenAI och som stöds på platinanivå av AWS, Bloomberg, Cloudflare, Google och Microsoft. Vid den tidpunkten hade MCP passerat 97 miljoner SDK-nedladdningar i månaden och över 10 000 publicerade servrar, med förstklassigt klientstöd i ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot och VS Code.

För en beslutsfattare som inte är utvecklare är det den här skillnaden som spelar roll. När en assistent läser din webbplats tolkar den ett dokument: den kan läsa en tabell fel, missa en fotnot eller blanda ihop två varianter. När en assistent anropar din MCP-server frågar den ett system: den efterfrågar artikeln, får tillbaka fälten och rapporterar dem. Det första läget ger rimliga svar. Det andra ger korrekta – förutsatt att datan bakom är korrekt, och det är där merparten av det verkliga arbetet ligger.

Vilka i branschen har redan lanserat en?

Det här är inte längre spekulation, och exemplen är nyttigt olika:

• Microchip Technology lanserade en kostnadsfri, publik MCP-server den 6 november 2025, som exponerar verifierade produktspecifikationer, datablad, lagersaldon, priser och ledtider över MCP Streamable HTTP, med JSON-kodade svar riktade till copiloter, chattbottar och företagsagenter.
• Siemens driver en publik server på mcp.siemens.com vars dokumenterade plugins – assets, utvecklarportal, sökning och webbinnehåll – är tillgängliga utan autentisering.
• Zoovu lanserade en MCP-server den 11 december 2025 som ger agenter styrd åtkomst till produktdata, positionerad kring korrekthet i frågor om kompatibilitet och användningsområde.
• ECIA lanserade TrustedParts.com Inventory AI Agent Service den 11 juni 2026 och gjorde därmed auktoriserat lagersaldo för elektronikkomponenter tillgängligt inuti Microsoft Copilot, ChatGPT och Claude.
• Shopify exponerar en Storefront MCP-server i butiker på https://{shop}.myshopify.com/api/mcp, med verktyg som search_catalog, lookup_catalog och get_product, och utan krav på autentisering för storefront-nivån.

Två mönster är värda att notera. Vart och ett av dessa vilar på ett befintligt auktoritativt datalager. Och vart och ett av dem drar en gräns mellan publika katalogdata och allt som är kommersiellt känsligt.

Verktyg eller resurser – vad bör en artikelserver använda?

Specifikationen är tydlig med skillnaden, och att göra fel ger en server som modeller använder dåligt.

Verktyg är modellstyrda. Specifikationen slår fast att verktyg ”är utformade för att vara modellstyrda, vilket innebär att språkmodellen kan upptäcka och anropa verktyg automatiskt utifrån sin kontextuella förståelse och användarens prompter”. Upptäckt sker med tools/list, anrop med tools/call. Varje verktyg bär ett inputSchema (JSON Schema 2020-12 som standard), ett valfritt outputSchema, och returnerar structuredContent som följer det schemat.

Resurser är applikationsdrivna. Specifikationen slår fast att resurser ”är utformade för att vara applikationsdrivna, där värdapplikationerna avgör hur kontext ska införlivas utifrån sina behov” – typiskt en väljare, en lista eller automatisk inkludering från värden. Varje resurs identifieras av en URI, och mallar gör det möjligt att parametrisera dem.

En katalog är ett sökrum, inte en fast dokumentmängd. Ingen vill scrolla igenom en resursväljare med 40 000 artiklar. Så merparten av en artikelserver bör vara verktyg, med två förfiningar: använd innehållsblock av typen resource_link för att peka på datablad och CAD-filer i stället för att bädda in stora nyttolaster, och reservera egentliga resurser för en handfull stabila dokument, till exempel en klassificeringsordlista eller en ändringslogg.

Två detaljer i den nuvarande specifikationen är värda uppmärksamhet. Verktygslistor får inte variera per anslutning, men får variera med den auktorisering som skickas med förfrågan. Och servrar bör returnera verktygen i deterministisk ordning, eftersom stabil ordning låter klienter cacha listan och förbättrar träffgraden i prompt-cachen.

Vad ändrades i specifikationen 2026-07-28?

Den här revisionen gjorde om transporten, och varje design som skrivits utifrån 2025 års material kommer att vara fel på specifika punkter.

Transportens utformning är numera välgörande tråkig. Servern exponerar en enda MCP-endpoint som tar emot POST – till exempel https://example.com/mcp. Varje JSON-RPC-förfrågan är sin egen POST. Klienter måste skicka en Accept-header som anger både application/json och text/event-stream, plus en MCP-Protocol-Version-header som måste stämma med värdet i _meta i kroppen, annars måste servern avvisa med 400 och felet HeaderMismatch. Servrar måste validera Origin-headern och svara 403 om den finns med och är ogiltig.

Den praktiska konsekvensen för infrastrukturteam: eftersom det inte finns någon session på protokollnivå driftsätts din MCP-server bakom en vanlig round-robin-lastbalanserare, precis som vilken annan tillståndslös HTTP-tjänst som helst. Roots, Sampling och Logging är nu avvecklade med minst tolv månaders varsel, och den gamla HTTP+SSE-transporten är formellt avvecklad den också.

Hur skyddar du pris och lager med OAuth?

Auktorisering är valfri i MCP, vilket är precis rätt för en artikelserver: den publika katalogen ska inte kräva någon token alls, och bara kommersiellt känsliga verktyg ska begära legitimation.

När du väl implementerar den är kraven specifika. MCP-servern fungerar som en OAuth 2.1-resursserver, enligt IETF-utkastet för OAuth 2.1. Den måste implementera Protected Resource Metadata (RFC 9728), och klienter måste använda den metadatan för att hitta auktoriseringsservern. Klienter måste implementera Resource Indicators (RFC 8707) och skicka en resource-parameter som identifierar din kanoniska server-URI i både auktoriserings- och tokenförfrågningar, och din server måste validera att token har utfärdats för den som avsedd mottagare. Auktoriseringsservrar bör returnera parametern iss enligt RFC 9207, och klienter måste validera den. Dynamic Client Registration är nu avvecklad till förmån för Client ID Metadata Documents, men finns kvar för bakåtkompatibilitet.

Mönstret som fungerar för en distributör eller tillverkare:

1. 01Oautentiserad nivå – specifikationer, parametrisk sökning, alternativ, efterlevnadsdokument, CAD-länkar och listpriser där du publicerar dem.
2. 02Autentiserad nivå – avtalspriser, kundspecifik tillgänglighet, offertskapande. Begär legitimation med en 403 och error="insufficient_scope", och namnge de scopes som krävs så att klienten kan höja behörigheten på en enda tur och retur i stället för flera.
3. 03Använd aldrig ett kundnummer i ett verktygsargument som enda åtkomstkontroll. Ett handtag är ett namn, inte en behörighet; validera auktorisering vid varje anrop.

Vad bör en MCP-server för artikeldata exponera?

Sex till åtta verktyg är rätt storleksordning. Fler än så och modellens val av verktyg försämras.

En verktygsdefinition ska se helt oanmärkningsvärd ut, och det är själva poängen:

{
  "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
  }
}

Lägg märke till vad beskrivningen gör: den talar om för modellen vad verktyget returnerar och när den i stället ska välja ett annat verktyg. Just den vanan gör mer för svarskvaliteten än hur mycket schemapolering som helst.

Ett genomarbetat exempel

En konstruktör hos en kontraktstillverkare i Texas ska ersätta en utgående artikel i ett kretskort som också levereras till en tysk apparatskåpsbyggare. Assistenten har tillverkarens MCP-server ansluten.

Konstruktör: Vår 60 V N-kanals-MOSFET i buck-steget går mot end-of-life. Jag behöver en drop-in i samma kapsel, R_DS(on) inte sämre än 12 milliohm vid 10 V gatespänning, och jag behöver veta om den faktiskt finns tillgänglig.

Assistenten gör fyra anrop.

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

Assistenten svarar sedan: den ena kandidaten är en drop-in med lägre kanalresistans och högre gateladdning, värd att kontrollera mot gatedrivaren; den andra klarar fotavtrycket men missar gränsen för R_DS(on); lagersaldot är 14 200 i Texas och 3 800 i Baden-Württemberg per i morse, med åtta veckors ledtid; RoHS- och REACH-deklarationer bifogas med sina utfärdandedatum.

Inget av det här är imponerande som teknik. Det är imponerande som affär. Tre inköpsbeslut fattades utan att en människa öppnade en webbläsare, och varje siffra kan spåras till en tidsstämplad post.

Vilka kan faktiskt nå din server i dag?

Var ärlig mot din styrelse om det här, för svaret är snävare än vad de flesta leverantörsmaterial antyder.

MCP når alltså ingenjörer med en assistent de själva konfigurerar, och företagsköpare vars IT-funktion registrerar din server. Det är en liten population med webbmått mätt och en mycket stor med pipelinemått mätt.

Hur upptäcker agenter din server?

Det finns ingen upptäckt på DNS-nivå. Tre mekanismer existerar:

1. 01Det officiella MCP-registret på registry.modelcontextprotocol.io, det centraliserade metadataregistret för publikt åtkomliga servrar, som backas av Anthropic, GitHub, Microsoft och PulseMCP. Det är öppen källkod, stöder underregister och är fortfarande i förhandsversion inför allmän tillgänglighet – räkna alltså med förändringar.
2. 02Kataloger på klientsidan, till exempel connectors-katalogen i Claude och app-katalogen i ChatGPT, var och en med sin egen granskningsprocess.
3. 03Din egen dokumentation. I dag är det så de flesta anslutningar faktiskt uppstår: en utvecklarsida anger endpoint-URL, verktygslistan och auktoriseringsscopen, och en kund klistrar in den i sin klient.

Publicera ditt .well-known/oauth-protected-resource-dokument även om de flesta verktyg är publika, och versionshantera endpointens sökväg. Du kommer att ändra din verktygsyta, och du vill att det ska bli en medveten migrering snarare än ett tyst haveri.

En checklista för implementationen

1. 01Konsolidera till en kanonisk post per artikel med typade attribut, enheter, ursprung och en tidsstämpel för senaste verifiering. Börja inte med protokollet.
2. 02Välj sex till åtta verktyg och skriv beskrivningar som säger när man inte ska använda respektive verktyg.
3. 03Deklarera utdatascheman och returnera structuredContent. Ta med enheter och verifieringsdatum i varje nyttolast.
4. 04Tillhandahåll en enda POST-endpoint där Mcp-Method- och Mcp-Name-headers respekteras, Origin valideras och ttlMs och cacheScope sätts på listresultat.
5. 05Dela upp publika och skyddade verktyg, implementera metadata enligt RFC 9728, validera tokens mottagare enligt RFC 8707 och använd scope-utmaningar för att höja behörigheten på en enda tur och retur.
6. 06Returnera verktygen i deterministisk ordning och håll verktygsnamnen stabila så att klienternas cachar fungerar.
7. 07Logga varje anrop – verktyg, argument, svarstid och om uppslaget gav träff. En MCP-server utan analys är en kanal du inte kan styra.
8. 08Följ upp korrektheten mot facit, löpande. Ett verktyg som självsäkert returnerar ett inaktuellt märkvärde är sämre än inget verktyg alls.

Partsgraph levererar det här som ett hanterat lager: vi konsoliderar din befintliga katalog till en verifierad Parts Graph, driftar MCP-endpointen med OAuth på de skyddade nivåerna, och rapporterar vilka agenter som anropade vad och var svaren blev fel.

Vill du veta var du står innan du skriver en enda rad kod – kör din domän genom det kostnadsfria testverktyget på /audit. Det kontrollerar vad maskiner i dag kan nå i din katalog, och om en MCP-endpoint över huvud taget skulle ha något tillförlitligt att leverera.