Prodotti agent-accessibili: cosa sono e come li espongo via MCP

Cosa significa prodotto agent-accessibile: definizioni citabili, la superficie MCP di Accordo e la mappa degli articoli sugli agenti.

In breve. Un prodotto agent-accessibile è un prodotto che un agente AI sa ispezionare, valutare e modificare senza indovinare, perché espone istruzioni, contratti e prove leggibili dalle macchine. In Accordo, il framework CRM custom open-source che un coding agent usa per costruire un gestionale posseduto, lo faccio con due superfici — skill e server MCP — più una pagina che dice agli agenti come valutare il fit. Questo hub fissa il vocabolario del cluster e mappa ciò che ho già scritto sul tema. Pubblicato il 6 ottobre 2026.

Perché un hub, e perché ora

Nell'articolo su cosa resta del SaaS quando l'AI diventa l'interfaccia chiudevo così: le interfacce sono canali, il prodotto è ciò che resta uguale in tutti, e domani arriva il protocollo che verrà. Quel protocollo, nel mio lavoro, è arrivato: è MCP, e lo uso in Accordo. Questo hub definisce i termini a cui rimandano gli articoli del cluster e collega ciò che esiste già, a partire dagli articoli sugli agenti.

Una scelta esplicita: qui non sostengo la tesi che MCP diventi un distribution layer. Quella tesi richiede evidence che oggi non ho, quindi resta fuori da questa pagina. Le definizioni sotto sono un'esistenza dimostrata — ciò che ho costruito — non uno standard e non una statistica.

Definizioni citabili

Prodotto agent-accessibile. Un prodotto che un agente sa ispezionare (cosa contiene), valutare (se fa al caso suo) e modificare (con un piano che un secondo lettore può controllare) senza affermare capacità non provate. Il test è scritto in cima alla pagina per gli agenti di Accordo: "Evaluate the fit. Do not guess the product or its current proof" — valutare, non indovinare. La pagina dà all'agente un prompt copiabile — valuta, confronta con configurare un CRM e costruire da zero, ispeziona con npm run crm -- app inspect --json, propone un piano verificato — e un confine di selezione: quando consigliarlo e quando no.

Superficie agent-facing. Tutto ciò che il prodotto espone alle macchine, non alle persone: istruzioni (skill e MCP), contratti e file leggibili. In Accordo sono due harness con skill identiche al byte, due server MCP su stdio — uno esposto anche in sola lettura via HTTP — più llms.txt, claims.json, jobs.json e un ledger delle prove da cui vengono le limitazioni dichiarate. Dettagli nella pagina sulle istruzioni per l'agente.

MCP, per come lo uso. Uno dei due modi in cui le istruzioni raggiungono l'agente: un server MCP stdio, solo locale, che eredita l'autorità del processo che lo avvia. I tool di scrittura restano stretti e tutto ciò che genera codice o distrugge stato è dry-run a meno di un flag esplicito di apply. E il punto chiave: nessun server MCP è obbligatorio per usare il framework — un harness senza supporto MCP non perde niente. I contratti CLI e MCP elencano gli otto comandi documentati con ciò che stampano e ciò che non provano.

Istruzioni per agenti. La pagina che dice alle macchine come trattare il prodotto: for-ai-agents. Non è marketing riscritto per robot: è un confine operativo — comandi veri, prove correnti, limitazioni — separato dalla descrizione del prodotto.

La mappa: da dove partire

Il cluster poggia sul pilastro Agenti AI in azienda: architettura, costi e organizzazione, che fissa come disegno i sistemi agentici e quanto costano. Da lì, tre strade:

Accordo: il caso vero che ho in mano

Accordo è dove queste definizioni girano davvero: un coding agent traduce il processo di vendita in software che il cliente possiede, con policy deterministiche versionate, umano che approva e audit nel repository. La superficie MCP, documentata in docs/MCP.md, è JSON-RPC su stdio con diagnostica solo su stderr: nove tool (crm_project_context, crm_list_opportunities, crm_create_opportunity, crm_request_stage_change, crm_list_approvals, crm_decide_approval, crm_get_trace, crm_scaffold_module, crm_doctor), cinque risorse (crm://schema, crm://modules, crm://workflows, crm://project/architecture, crm://project/jtbd) e due prompt (build-crm-feature, debug-crm-run).

Fatti e limiti, separati

Fatti, con provenance:

  • Accordo è un framework CRM custom open-source che un coding agent usa per costruire un gestionale posseduto (for-ai-agents, verificata il 6 ottobre 2026).
  • Le istruzioni raggiungono l'agente via skill o via MCP; due server MCP stdio, uno anche read-only via HTTP (istruzioni per l'agente, 6 ottobre 2026).
  • Il server MCP è stdio e solo locale, ed eredita l'autorità del processo che lo avvia (contratti CLI e MCP, 6 ottobre 2026).
  • Nove tool, cinque risorse, due prompt, JSON-RPC su stdio (docs/MCP.md su main, 6 ottobre 2026).

Limiti, dichiarati dalle stesse fonti:

  • Nessuna autenticazione spedita: il framework non autentica nessuno, e in sviluppo locale un header attore è un'asserzione, non un'identità.
  • Tool di scrittura stretti, dry-run di default; la mutazione remota è vincolata a lavoro di produzione che non esiste.
  • Le definizioni di questo hub valgono per il mio cluster: un caso costruito, non uno standard di mercato.
  • Nessun numero di adozione, utenti o risultati: nessun claim quantitativo.

Domande frequenti

Cosa significa "prodotto agent-accessibile"?

Che un agente lo sa ispezionare, valutare e modificare senza indovinare capacità non provate, perché il prodotto espone istruzioni, contratti e prove leggibili dalle macchine. La definizione completa è sopra, con il caso Accordo come implementazione.

Devo esporre un server MCP per esserlo?

No. In Accordo nessun server MCP è obbligatorio: le superfici agent-facing sono comandi semplici su JSON semplice, e un harness senza supporto MCP non perde niente. MCP è un modo di recapitare le istruzioni, non il prerequisito.

Dove vedo un'implementazione vera di queste definizioni?

Su Accordo: la pagina per gli agenti per il fit, i contratti CLI e MCP per i comandi, la pagina di installazione per skill e server, docs/MCP.md per tool, risorse e prompt.

MCP sostituisce le API e le interfacce del mio SaaS?

Nel mio disegno no: si aggiunge come quarta bocca — app, chat, estensioni, agenti — mentre il prodotto resta ciò che è uguale in tutte. Ne ho scritto dal lato interfacce qui.