MCP come distribution layer: cosa mostrano due server veri

Due server MCP veri: 9 tool locali su Accordo, 40 tool hosted su Arvo e 5 fix per client. La tesi distribution layer come ipotesi, con fatti e limiti.

In breve. MCP distribuisce un prodotto quando un client esterno lo legge e lo usa senza indovinare. Ho due casi veri: il server locale di Accordo con nove tool e il server hosted di Arvo con quaranta tool letto da ChatGPT e Claude. La tesi, che nel hub sui prodotti agent-accessibili avevo lasciato fuori per mancanza di evidence, qui diventa un'ipotesi con fatti e limiti dichiarati: la distribuzione funziona quando la superficie si adatta a chi legge.

Il locale: nove tool che non viaggiano

Il server applicativo di Accordo espone nove tool, cinque risorse e due prompt su JSON-RPC via stdio, con diagnostica solo su stderr. Accanto gira un secondo server, quello documentazione, con tre tool sopra docs e ledger. Solo il secondo viaggia in rete, in sola lettura su https://accordo.dev/api/mcp. Le regole che contano: scrittura stretta, generazione in dry-run senza flag esplicito, exit code 0/1/2 identici sulle due superfici. Le ho raccontate nelle 5 lezioni da un MCP server vero, con le definizioni nel hub MCP.

Questo server distribuisce poco e bene: resta locale, eredita l'autorita del processo che lo avvia, non autentica nessuno. E la prima forma di distribuzione: le istruzioni raggiungono l'agente anche senza MCP, perche le skill restano disponibili. MCP qui recapita, non vincola.

L'hosted: quaranta tool letti da due client

Arvo espone lo stesso server hosted a ChatGPT e a Claude. Il 21 settembre 2026 Claude Connect mostra 40 tool e li azzera, cinque volte per cinque motivi diversi: OAuth senza resource, versione di protocollo 2025-11-25 non accettata, securitySchemes di ChatGPT nel payload, chiavi widget su _meta piu GET che rispondeva 405, title letto dalle annotations. Cinque PR in un giorno, una per causa. La storia completa sta in un server MCP, due client.

Il catalogo interno resta uno. Le superfici pubblicate diventano due: ChatGPT tiene le _meta widget, Claude riceve una tools/list pulita. Il numero non era il problema, la forma si. Quaranta tool andavano bene quando ogni client riceveva la sua forma.

La regola: dentro uno, fuori uno per client

I due casi dicono la stessa cosa da due lati. Dentro, un solo catalogo con controlli sugli scope. Fuori, una superficie per ogni lettore, adattata a come parsa, autentica e registra. Accordo separa cio che muta da cio che informa e mette in rete solo il secondo. Arvo tiene un catalogo e pubblica due forme. La distribuzione non sta nel protocollo da solo: sta nel catalogo unico piu le forme per client, con dry-run, exit code e limiti leggibili dalle macchine.

Fatti e ipotesi

FACT. Il server applicativo di Accordo espone nove tool, cinque risorse e due prompt su stdio; quello documentazione espone tre tool ed e raggiungibile anche in sola lettura via HTTP. La diagnostica esce solo su stderr.

FACT. Il 21 settembre 2026 lo stesso server hosted di Arvo mostra 40 tool a Claude Connect e li azzera cinque volte per cinque cause distinte, chiuse in cinque PR. Il probe live mostra errore con header 2025-11-25 e 40 tool con 2025-06-18.

FACT. Nel hub avevo scritto che la tesi distribution layer richiedeva evidence che non avevo, e nelle pagine su come farmi trovare dalle AI avevo separato farsi trovare da distribuire. Queste due pagine restano il perimetro: definizioni dimostrate, non standard di mercato.

HYPOTHESIS. MCP diventa distribution layer quando il prodotto espone un catalogo unico e una superficie per client, con istruzioni, contratti e limiti leggibili dalle macchine. E la mia lettura dopo i due server, non un dato misurato sul mercato.

Limiti: due server costruiti da me, due client, un giorno di fix. Nessun numero di adozione, nessun utente contato, nessun confronto tra implementazioni. Cinque fix in un giorno non sono una statistica sui client MCP.

Domande frequenti

MCP da solo distribuisce il mio prodotto?

No. Distribuisce quando un client esterno legge il catalogo e lo usa senza indovinare. Servono istruzioni, contratti e limiti in formato macchina, piu una superficie adattata a ogni client.

Quanti tool devo esporre per essere distribuito?

Il conteggio non decide. Nove tool locali bastano quando restano locali; quaranta hosted funzionano quando ogni client riceve la sua forma. Prima la forma giusta per chi legge, poi il budget sui tool.

Devo scegliere tra MCP e API?

Nel mio disegno MCP si aggiunge: app, chat, estensioni e agenti sono quattro bocche dello stesso prodotto. Cio che muta resta locale, cio che informa puo viaggiare. Il prodotto resta cio che non cambia tra le bocche.