MCP per i produttori: guida pratica

Che cos'è MCP, in parole semplici?

Il Model Context Protocol è un modo standard con cui un assistente IA chiama il sistema di qualcun altro e ne riceve una risposta tipizzata e strutturata.

Anthropic lo ha rilasciato in open source il 25 novembre 2024, descrivendolo come "un nuovo standard per collegare gli assistenti IA ai sistemi in cui risiedono i dati". Il 9 dicembre 2025 Anthropic ha donato MCP alla Agentic AI Foundation, un fondo dedicato della Linux Foundation cofondato con Block e OpenAI e sostenuto a livello platinum da AWS, Bloomberg, Cloudflare, Google e Microsoft. A quella data MCP aveva superato i 97 milioni di download mensili degli SDK e i 10.000 server pubblicati, con supporto client di primo livello in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e VS Code.

Per un decisore non tecnico, la distinzione che conta è questa. Quando un assistente legge il vostro sito web sta interpretando un documento: può fraintendere una tabella, saltare una nota a piè di pagina o confondere due varianti. Quando un assistente chiama il vostro server MCP sta interrogando un sistema: chiede il componente, riceve i campi e li riporta. La prima modalità produce risposte plausibili. La seconda produce risposte corrette — a patto che siano corretti i dati che stanno dietro, ed è lì che si concentra la maggior parte del lavoro vero.

Chi ne ha già rilasciato uno in questo settore?

Non è più uno scenario ipotetico, e gli esempi sono utilmente eterogenei:

• Microchip Technology ha lanciato un server MCP pubblico e gratuito il 6 novembre 2025, che espone specifiche di prodotto verificate, schede tecniche, giacenze, prezzi e tempi di consegna tramite MCP Streamable HTTP, con risposte codificate in JSON pensate per copilot, chatbot e agenti aziendali.
• Siemens gestisce un server pubblico su mcp.siemens.com, i cui plugin documentati — asset, developer portal, ricerca e contenuti web — sono disponibili senza autenticazione.
• Zoovu ha lanciato un server MCP l'11 dicembre 2025 che dà agli agenti un accesso governato ai dati di prodotto, posizionato sull'accuratezza nelle domande di compatibilità e di applicazione.
• ECIA ha lanciato l'Inventory AI Agent Service di TrustedParts.com l'11 giugno 2026, rendendo disponibili le giacenze autorizzate di componenti elettronici dentro Microsoft Copilot, ChatGPT e Claude.
• Shopify espone un server MCP Storefront sugli store all'indirizzo https://{shop}.myshopify.com/api/mcp, con strumenti fra cui search_catalog, lookup_catalog e get_product, e senza autenticazione richiesta per il livello storefront.

Vale la pena notare due costanti. Ognuno di questi server poggia su un archivio dati autorevole già esistente. E ognuno traccia una linea netta fra i dati pubblici di catalogo e tutto ciò che è commercialmente sensibile.

Strumenti o risorse: che cosa deve usare un server di componenti?

La specifica è esplicita sulla differenza, e sbagliarla produce un server che i modelli usano male.

Gli strumenti sono controllati dal modello. La specifica afferma che gli strumenti "sono progettati per essere model-controlled, il che significa che il modello linguistico può scoprirli e invocarli automaticamente in base alla propria comprensione del contesto e ai prompt dell'utente". La scoperta avviene con tools/list, l'invocazione con tools/call. Ogni strumento porta con sé un inputSchema (JSON Schema 2020-12 per impostazione predefinita), un outputSchema facoltativo, e restituisce structuredContent conforme a quello schema.

Le risorse sono guidate dall'applicazione. La specifica afferma che le risorse "sono progettate per essere application-driven, con le applicazioni host che decidono come incorporare il contesto in base alle proprie esigenze" — tipicamente un selettore, un elenco o l'inclusione automatica da parte dell'host. Ogni risorsa è identificata da un URI e i template consentono URI parametrizzati.

Un catalogo è uno spazio di query, non un insieme fisso di documenti. Nessuno vuole scorrere un selettore di risorse che contiene 40.000 componenti. Perciò un server di componenti deve essere fatto in larga parte di strumenti, con due accortezze: usare blocchi di contenuto resource_link per puntare a schede tecniche e file CAD invece di incorporare payload di grandi dimensioni, e riservare le risorse vere e proprie a una manciata di documenti stabili, come un dizionario di classificazione o un registro delle modifiche.

Due dettagli della specifica attuale meritano attenzione. Gli elenchi di strumenti non devono variare da connessione a connessione, ma possono variare in base all'autorizzazione presentata nella richiesta. E i server dovrebbero restituire gli strumenti in un ordine deterministico, perché un ordinamento stabile permette ai client di mettere in cache l'elenco e migliora il tasso di successo della cache dei prompt.

Che cosa è cambiato nella specifica 2026-07-28?

Questa revisione ha rimodellato il trasporto, e qualsiasi progetto scritto su materiale del 2025 sarà sbagliato in punti precisi.

La forma del trasporto è ora piacevolmente noiosa. Il server espone un unico endpoint MCP che accetta POST — per esempio https://example.com/mcp. Ogni richiesta JSON-RPC è una POST a sé. I client devono inviare un header Accept che elenca sia application/json sia text/event-stream, più un header MCP-Protocol-Version che deve corrispondere al valore presente in _meta nel corpo, altrimenti il server deve rifiutare con un 400 e un errore HeaderMismatch. I server devono validare l'header Origin e rispondere 403 se è presente e non valido.

La conseguenza pratica per i team infrastrutturali: poiché non esiste una sessione a livello di protocollo, il vostro server MCP si distribuisce dietro un semplice load balancer round-robin, come qualsiasi altro servizio HTTP stateless. Roots, Sampling e Logging sono ora deprecati con una finestra minima di dodici mesi, e anche il vecchio trasporto HTTP+SSE è formalmente deprecato.

Come si proteggono prezzi e stock con OAuth?

L'autorizzazione in MCP è facoltativa, il che è esattamente ciò che serve a un server di componenti: il catalogo pubblico non dovrebbe richiedere alcun token e solo gli strumenti commercialmente sensibili dovrebbero chiedere le credenziali.

Quando la si implementa, i requisiti sono precisi. Il server MCP agisce come resource server OAuth 2.1, secondo la bozza IETF di OAuth 2.1. Deve implementare i Protected Resource Metadata (RFC 9728) e i client devono usare quei metadati per individuare l'authorization server. I client devono implementare i Resource Indicators (RFC 8707), inviando un parametro resource che identifica l'URI canonico del vostro server sia nelle richieste di autorizzazione sia in quelle di token, e il vostro server deve verificare che i token siano stati emessi per sé come audience prevista. Gli authorization server dovrebbero restituire il parametro iss secondo la RFC 9207 e i client devono validarlo. La Dynamic Client Registration è ora deprecata a favore dei Client ID Metadata Documents, pur restando disponibile per retrocompatibilità.

Lo schema che funziona per un distributore o un produttore:

1. 01Livello non autenticato — specifiche, ricerca parametrica, alternative, documenti di conformità, link ai file CAD, prezzi di listino dove li pubblicate.
2. 02Livello autenticato — prezzi contrattuali, disponibilità specifica per cliente, creazione di offerte. Rispondete con un 403 e error="insufficient_scope", indicando gli scope necessari perché il client possa fare lo step-up in un solo round trip anziché in diversi.
3. 03Mai usare un identificativo cliente in un argomento di uno strumento come unico controllo di accesso. Un handle è un nome, non una capability: validate l'autorizzazione a ogni chiamata.

Che cosa deve esporre un server MCP di componenti?

Da sei a otto strumenti è l'ordine di grandezza giusto. Oltre quella soglia la selezione da parte del modello peggiora.

Una definizione di strumento deve apparire del tutto ordinaria, ed è proprio questo il punto:

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

Notate che cosa fa la descrizione: dice al modello che cosa restituisce lo strumento e quando conviene invece ricorrere a un altro strumento. Quella singola abitudine fa più per la qualità delle risposte di qualsiasi rifinitura degli schemi.

Un esempio concreto

Un ingegnere progettista di un contract manufacturer in Texas sta sostituendo un componente a fine vita in una scheda che viene fornita anche a un costruttore di quadri elettrici tedesco. L'assistente ha collegato il server MCP del produttore.

Ingegnere: Il MOSFET a canale N da 60 V del nostro stadio buck sta andando a fine vita. Mi serve un sostituto drop-in nello stesso package, con R_DS(on) non peggiore di 12 milliohm a 10 V di pilotaggio di gate, e devo sapere se è davvero disponibile.

L'assistente effettua quattro chiamate.

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

L'assistente risponde poi così: un candidato è un drop-in con resistenza di conduzione migliore e carica di gate più alta, da verificare rispetto al gate driver; il secondo rispetta il footprint ma non rientra nel limite di R_DS(on); a stamattina la disponibilità è di 14.200 pezzi in Texas e 3.800 nel Baden-Württemberg, con otto settimane di lead time; le dichiarazioni RoHS e REACH sono allegate con le rispettive date di emissione.

Nulla di tutto questo è notevole sul piano ingegneristico. Lo è sul piano commerciale. Tre decisioni di approvvigionamento sono state prese senza che una persona aprisse un browser, e ogni dato è tracciabile fino a un record con marca temporale.

Chi può davvero raggiungere il vostro server oggi?

Siate onesti su questo punto con il vostro consiglio di amministrazione, perché la risposta è più circoscritta di quanto lasci intendere gran parte del materiale dei fornitori.

MCP raggiunge quindi gli ingegneri che si configurano un assistente e i buyer aziendali il cui reparto IT registra il vostro server. È una popolazione piccola secondo gli standard del web e molto grande secondo gli standard della pipeline commerciale.

Come fanno gli agenti a scoprire il vostro server?

Non esiste discovery a livello di DNS. I meccanismi sono tre:

1. 01Il registry ufficiale MCP su registry.modelcontextprotocol.io, il repository centralizzato di metadati per i server accessibili pubblicamente, sostenuto da Anthropic, GitHub, Microsoft e PulseMCP. È open source, supporta i sub-registry e resta in preview prima della disponibilità generale: aspettatevi quindi dei cambiamenti.
2. 02Le directory lato client, come la directory dei connettori di Claude e la directory delle app di ChatGPT, ciascuna con il proprio processo di revisione.
3. 03La vostra documentazione. Oggi è così che nasce la maggior parte dei collegamenti: una pagina per sviluppatori indica l'URL dell'endpoint, l'elenco degli strumenti e gli scope di autorizzazione, e un cliente lo incolla nel proprio client.

Pubblicate il documento .well-known/oauth-protected-resource anche se la maggior parte degli strumenti è pubblica, e versionate il percorso dell'endpoint. La superficie dei vostri strumenti cambierà, ed è meglio che quel cambiamento sia una migrazione deliberata e non una rottura silenziosa.

Una checklist di implementazione

1. 01Riconducete tutto a un unico record canonico per componente, con attributi tipizzati, unità di misura, provenienza e un timestamp di ultima verifica. Non partite dal protocollo.
2. 02Scegliete da sei a otto strumenti e scrivete descrizioni che dicano quando non usare ciascuno di essi.
3. 03Dichiarate gli schemi di output e restituite structuredContent. Includete unità di misura e date di verifica in ogni payload.
4. 04Servite un unico endpoint POST, con gli header Mcp-Method e Mcp-Name rispettati, Origin validato e ttlMs e cacheScope impostati nei risultati di list.
5. 05Separate gli strumenti pubblici da quelli protetti, implementate i metadati RFC 9728, verificate l'audience dei token secondo la RFC 8707 e usate le sfide sugli scope per fare lo step-up in un solo round trip.
6. 06Restituite un ordinamento deterministico degli strumenti e nomi stabili, così che le cache dei client funzionino.
7. 07Registrate ogni chiamata — strumento, argomenti, latenza e se la ricerca ha prodotto un risultato. Un server MCP senza analytics è un canale che non potete governare.
8. 08Monitorate l'accuratezza rispetto ai dati di riferimento, in modo continuo. Uno strumento che restituisce con sicurezza un valore nominale obsoleto è peggio di nessuno strumento.

Partsgraph offre tutto questo come livello gestito: risolviamo il vostro catalogo esistente in un unico Parts Graph verificato, ospitiamo l'endpoint MCP con OAuth sui livelli protetti e vi riportiamo quali agenti hanno chiamato che cosa e dove le risposte erano sbagliate.

Se volete sapere a che punto siete prima di scrivere una riga di codice, analizzate il vostro dominio con il grader gratuito su /audit: verifica che cosa le macchine riescono oggi a raggiungere nel vostro catalogo e se un endpoint MCP avrebbe qualcosa di affidabile da servire.