Hai messo a punto un ottimo prompt per un refactor di codice in Cursor 3. Il giorno dopo l'hai cercato in Claude Code e non c'era, così l'hai riscritto a memoria. Una settimana più tardi ti sei ritrovato a fare la stessa cosa in Windsurf, e il prompt è derivato di nuovo. Tre fork dello stesso prompt vivono ora in tre posti, tutti leggermente diversi, nessuno revisionato a confronto degli altri.
La soluzione a livello di protocollo per questo problema esiste, ed è più matura di quanto la maggior parte degli sviluppatori si renda conto. Model Context Protocol ha superato i 97 milioni di install a marzo 2026 [1] e la roadmap ufficiale 2026 ha dichiarato l'enterprise readiness una priorità [2]. AWS, Google e Cloudflare spediscono integrazioni MCP. Claude Code, Cursor 3 e Windsurf sono tutti client MCP nativi.
Questa guida è la versione pratica. Non parleremo di strategia o governance: costruiremo un piccolo server MCP che espone un prompt, lo collegheremo ai tre IDE e vedremo come gestire il versionamento quando il prompt evolve. C'è una sezione su cosa MCP non risolve e un breve rimando a dove si inserisce Keep My Prompts se non vuoi costruire i pezzi mancanti da zero. Codice in Python, snippet di config per ogni strumento, niente fronzoli.
1. MCP in 60 secondi
MCP è un protocollo aperto che permette a qualsiasi client LLM di parlare con qualsiasi server esterno tramite un set fisso di primitive. Tre di queste contano per questa guida:
Tools: funzioni eseguibili che l'agent può chiamare (i verbi).
Resources: dati in sola lettura che l'agent può recuperare (i nomi).
Prompts: template e workflow riutilizzabili che il client può presentare all'utente o al modello.
L'architettura è un host che orchestra una sessione, client che si collegano ai server, server che espongono capabilities [3]. Due trasporti sono ampiamente diffusi: stdio per i processi locali e Streamable HTTP per i server remoti. Entrambi fanno parte della spec.
La primitiva interessante per le librerie di prompt è la terza. La maggior parte della copertura di MCP si concentra sui Tools perché è lì che avvengono i workflow agentici, ma Prompts è la primitiva che trasforma la tua libreria di prompt in un oggetto a livello di protocollo che qualsiasi client compatibile può scoprire e usare senza modifiche di codice.
2. La primitiva Prompts
Due metodi fanno tutto il lavoro: prompts/list e prompts/get.
prompts/list restituisce il catalogo. Ogni prompt ha un nome, una descrizione leggibile e un elenco opzionale di argomenti che il client può riempire:
{
"prompts": [
{
"name": "refactor-component",
"description": "Refactor a React component for performance and readability",
"arguments": [
{ "name": "file_path", "description": "Path to the component file", "required": true },
{ "name": "framework_version", "description": "React version", "required": false }
]
}
]
}
prompts/get restituisce il contenuto effettivo del prompt dato un nome e gli argomenti:
{
"description": "Refactor a React component for performance and readability",
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "Review the React component at src/components/Dashboard.tsx (React 19). Identify rendering bottlenecks, propose memoization where it actually helps, and rewrite the component preserving its public API. Return a unified diff."
}
}
]
}
Il client (Claude Code, Cursor 3, Windsurf, o un agent personalizzato) scopre il prompt tramite prompts/list, chiede all'utente di compilare gli argomenti, poi chiama prompts/get e passa i messaggi risultanti al modello. La stessa coppia JSON-RPC funziona su ogni client MCP.
Questo è il punto chiave. Una volta che un prompt vive dietro MCP, smetti di hardcodare i system prompt nello strato applicativo [4]. Diversi agent scoprono e usano lo stesso template senza che tu debba mantenere tre copie.
Vuoi sapere quanto sono efficaci i tuoi prompt? Prompt Score li analizza su 6 criteri.
from mcp.server.fastmcp import FastMCP
app = FastMCP("kmp-prompt-server")
@app.prompt()
def refactor_component(file_path: str, framework_version: str = "19") -> str:
"""Refactor a React component for performance and readability."""
return (
f"Review the React component at {file_path} (React {framework_version}). "
"Identify rendering bottlenecks, propose memoization where it actually "
"helps, and rewrite the component preserving its public API. "
"Return a unified diff."
)
@app.prompt()
def write_test(file_path: str, framework: str = "vitest") -> str:
"""Generate unit tests for a target file."""
return (
f"Read {file_path} and write {framework} unit tests covering the public "
"exports. Use existing project conventions if visible. Mock external "
"calls. Aim for one happy-path and one edge-case test per export."
)
if __name__ == "__main__":
app.run()
Lancialo:
python prompt_server.py
Questo è il server completo. Il decoratore @app.prompt() gestisce la boilerplate JSON-RPC e trasforma la firma della funzione nello schema di arguments che il client riceve. Una docstring diventa la description. Il valore di ritorno viene avvolto nell'array messages.
Due prompt bastano per dimostrare il pattern. In pratica, un vero server di prompt ha 20-100 voci che coprono refactor, generazione di test, code review, debug, stesura di ADR, template di commit message e qualunque altra cosa il tuo team usi ripetutamente.
Architettura: una libreria di prompt esposta tramite un server MCP, che si propaga a Claude Code, Cursor 3, Windsurf e agent personalizzati
4. Collegarlo ai tuoi IDE
Ogni IDE compatibile con MCP ha la sua posizione di config, ma la forma è la stessa: command, args, env opzionale.
Claude Code usa un helper CLI:
claude mcp add kmp-prompts \
--command python \
--args /Users/you/prompt_server.py
Dopo il riavvio, tutti e tre gli IDE espongono refactor-component e write-test come prompt scopribili nelle rispettive UI. Cursor 3 li elenca nell'agent panel, Claude Code li rende disponibili tramite slash command, Windsurf li raccoglie in Cascade. Il client decide la superficie, il server resta lo stesso.
Nota che lo schema di config è abbastanza stabile da copiarlo fra strumenti, ma i percorsi di lookup non sono ancora unificati. La roadmap 2026 segnala questo come gap di "configuration portability" [2]. Per ora, incolla lo stesso blocco nella config di ogni strumento.
5. Versionamento quando il prompt evolve
Un prompt vivo raramente resta invariato. La parte interessante delle librerie di prompt basate su MCP è la strategia per gestire il cambiamento senza rompere i client che si erano agganciati a un comportamento più vecchio.
I client si agganciano esplicitamente a refactor-component@v3 o galleggiano su refactor-component (l'ultima). Facile da ragionarci sopra, leggermente rumoroso se molte versioni convivono.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
Mantiene il catalogo pulito. Il client vede una singola voce chiamata refactor-component e seleziona la versione tramite argomenti. Funziona bene quando hai un registry sottostante che può rispondere alla domanda "dammi l'ultima versione di X con punteggio almeno 75".
Pattern 3: risoluzione lato server tramite registry.
Il server MCP è uno strato sottile davanti a un registry che possiede versioning, scoring e rollback. Il client non vede mai i numeri di versione. Il server sceglie l'ultima versione che ha passato i quality gate e la serve. Se il registry fa rollback, la prossima chiamata prompts/get restituisce automaticamente la versione precedente. I client continuano a funzionare.
È il pattern su cui converge la maggior parte dei team di produzione, perché lascia che il team della libreria di prompt avanzi (testa, valuta, promuove) senza toccare la config dei client. Il server MCP è scemo, il registry è intelligente.
Anatomia di una risposta prompt MCP: name, description, arguments, messages, con metadata per versione, score e last-updated sovrapposti
6. Streamable HTTP per setup multi-utente
stdio è ottimo per uno sviluppatore su una sola macchina. Due casi ti spingono al trasporto HTTP.
Server di prompt centralizzato per un team. Tutti nel team raggiungono lo stesso URL del server MCP invece di farne girare una copia in locale. I nuovi prompt arrivano a tutti i client senza che nessuno faccia git pull o riavvii un IDE.
Agent ospitati in cloud. Un agent personalizzato che gira su un server non può fare exec di un processo Python locale: può colpire un endpoint HTTP.
Il server HTTP minimale con FastMCP:
from mcp.server.fastmcp import FastMCP
app = FastMCP("kmp-prompt-server", host="0.0.0.0", port=8765)
@app.prompt()
def refactor_component(file_path: str) -> str:
"""Refactor a React component for performance and readability."""
return f"Review the component at {file_path}..."
if __name__ == "__main__":
app.run(transport="streamable-http")
Le sessioni stateful sono lo spigolo qui. La roadmap 2026 segnala esplicitamente che "le sessioni stateful litigano con i load balancer, lo scaling orizzontale richiede workaround" [2], e il lavoro in arrivo sullo Streamable HTTP stateless serve proprio a sistemarlo. Fino ad allora, fai girare una singola istanza dietro un proxy con session affinity e per qualsiasi team sotto i 100 seat sei a posto.
7. Cosa MCP non risolve
Una volta che hai un server di prompt che gira, diventa ovvio cos'è MCP e cosa non è. Il protocollo copre il trasporto. Non copre le cose che ti servono davvero per gestire una libreria di prompt.
Discovery oltre il catalogo.prompts/list ti dice i nomi, non quali prompt sono buoni, quali sono deprecati, quali hanno preso 90 e quali 50. La qualità è un tuo problema.
UX del versioning. Puoi implementare uno qualunque dei tre pattern visti sopra, ma MCP in sé non ha opinioni su rollback, confronto fianco a fianco o "quale versione è quella corrente".
Quality gate. Un prompt scadente esposto via MCP è scopribile come uno buono. Se non vuoi esporre un prompt che scende sotto una soglia, devi imporlo prima che il prompt entri nel server.
Audit e observability. Chi ha usato refactor-component@v3 la settimana scorsa? Con quali argomenti? Tramite quale client? La roadmap 2026 cita la observability strutturata come gap [2]. Oggi te lo logghi tu.
Non sono fallimenti di MCP: sono questioni di libreria di prompt. Il protocollo sposta byte fra client e server. Cosa vive lato server è affar tuo.
8. Keep My Prompts + MCP: un esempio completo
Qui si inserisce Keep My Prompts, e il confine è netto. Keep My Prompts tiene i prompt come oggetti canonici, versionati e valutati. Il server MCP è uno strato sottile davanti a Keep My Prompts che sceglie la versione giusta e la serve.
Un setup tipico:
I prompt vivono in Keep My Prompts, ognuno versionato e valutato su sei criteri (specificità, contesto, struttura, vincoli, ruolo, formato di output).
Il Promptimizer riscrive i prompt deboli; il quality gate rifiuta le varianti che non superano il punteggio dell'originale.
Il server MCP risolve un nome di prompt in "ultima versione che ha passato il quality gate", la legge da Keep My Prompts, la restituisce tramite prompts/get.
Claude Code, Cursor 3, Windsurf e qualsiasi agent personalizzato leggono la stessa libreria attraverso lo stesso protocollo.
La separazione è ciò che fa funzionare il tutto. MCP risolve la metà "come fanno i client a raggiungere il prompt". Keep My Prompts risolve la metà "il prompt è buono, è cambiato, chi altro lo sta usando". Ognuno da solo è incompleto.
Per gli sviluppatori in solitaria è eccessivo finché non hai più di una manciata di prompt. Per i piccoli team è il momento in cui la sofferenza multi-IDE smette di essere una tassa. Gratis per iniziare, nessuna carta di credito richiesta.
9. Il segnale
Tre cose vale la pena dirle in chiaro.
Primo, MCP non è "enterprise-ready" in senso stretto, non ancora. La roadmap 2026 segnala esplicitamente quattro gap aperti: audit trail, auth integrata SSO, comportamento dei gateway e portabilità della config [2]. Se lavori in un posto che richiede SSO e integrazione SIEM prima di spedire qualunque cosa, sei in anticipo.
Secondo, MCP è assolutamente production-ready per sviluppatori singoli e piccoli team. L'SDK Python è stabile, i tre client IDE più grandi spediscono con supporto MCP first-class e la primitiva Prompts è documentata e prevedibile. Il problema di drift con cui apriva questo articolo lo risolvi con circa 30 righe di Python.
Terzo, i wrapper che costruisci ora si capitalizzano. Il server MCP che hai scritto oggi continua a funzionare quando la spec aggiunge task asincroni, auth con scope e Streamable HTTP stateless. I client raccolgono nuove capability man mano che le implementano. Il tuo server di prompt non deve cambiare.
I team che spediscono più velocemente nel 2026 sono quelli che trattano la propria libreria di prompt come un asset a livello di protocollo, non come un artefatto da copia-incolla. Trenta righe di Python e un blocco di config in tre IDE sono un prezzo basso per la libreria di prompt che ti porti dietro.
Keep My Prompts ti permette di tenere un'unica libreria di prompt valutata e versionata, da mettere dietro un server MCP in pochi minuti. Gratis per iniziare, nessuna carta di credito richiesta. Per approfondire la strategia di prompt multi-IDE, vedi la nostra guida su Cursor 3 vs Claude Code vs Windsurf.
