Come gli agenti IA accedono al vostro BSS tramite CLI e MCP

Un cliente chiama un martedì pomeriggio e chiede quando verrà attivata la sua fibra. La persona al service desk apre l'anagrafica del cliente, poi l'ordine, poi il riscontro del partner di installazione, e compone la risposta da tre schermate. Un agente IA a cui viene posta la stessa domanda ha lo stesso problema, senza le schermate. Ha bisogno di un accesso definito a quei sistemi.

Questo articolo si rivolge al responsabile IT di un ISP, MVNO o rivenditore che ha sentito parlare di MCP e vuole sapere che cosa farne. Spiega che cosa offre un'interfaccia a riga di comando a un agente, che cos'è il Model Context Protocol, come si rapportano i due, come si presenta una prima integrazione sensata e che cosa pretendere da qualsiasi fornitore che offra l'una o l'altro.

Perché gli agenti hanno bisogno di un accesso definito

Le schermate sono fatte per le persone. Un agente che clicca attraverso un'interfaccia web si blocca quando un pulsante si sposta, e vede tutto ciò che l'utente connesso si trova a vedere. Le interfacce di programmazione danno agli agenti un accesso definito a dati e azioni: ogni operazione ha un nome, i suoi input sono descritti, il suo risultato ha una forma fissa e il sistema può verificare chi sta chiedendo prima di rispondere.

Per un operatore questo conta per un motivo pratico. La domanda «a che punto è questo ordine?» coinvolge il CRM, la gestione degli ordini, i riscontri del provisioning e talvolta la fatturazione. Se ognuno di questi sistemi risponde tramite un'operazione definita, un agente può combinarli come fa un buon dispatcher. Se rispondono solo tramite schermate, ogni progetto con agenti inizia con lo screen scraping, e ogni rilascio di ogni strumento può comprometterlo.

Che cosa offre una CLI a un agente

Un'interfaccia a riga di comando offre un insieme fisso di comandi. Un agente in grado di eseguire comandi su un computer li richiama e legge il risultato strutturato. Prendiamo uno strumento ipotetico chiamato bss e la verifica di un ordine:

$ bss order show 48213 --json
{
  "order": "48213",
  "customer": "C-10442",
  "product": "Fibre 1000",
  "state": "awaiting_installation",
  "appointment": "2026-11-04",
  "missing": ["ont_serial"]
}

L'agente non deve interpretare una pagina. Ottiene lo stato dell'ordine, l'appuntamento e l'unica cosa che blocca l'attivazione, e può spiegarlo a una persona con parole semplici o passarlo al comando successivo.

Una buona CLI per agenti ha alcune caratteristiche a cui vale la pena fare attenzione. Ogni comando può descrivere sé stesso (input, se legge o modifica qualcosa, quale permesso richiede), così l'agente può consultare un'operazione prima di eseguirla. I comandi sui dati restituiscono JSON su richiesta. Gli errori tornano come messaggi chiari con exit code stabili. Tutto ciò che modifica o invia qualcosa offre un dry run che mostra la richiesta senza eseguirla.

Una CLI gira dove gira l'agente, di solito sulla postazione di un collaboratore, e agisce con le credenziali di chi l'ha configurata. Per questo è adatta a chi lavora già con un agente alla propria scrivania, e ai controlli automatizzati con script che vengono eseguiti secondo una pianificazione.

Che cos'è MCP

Il Model Context Protocol (MCP) è uno standard open source per collegare applicazioni di IA a sistemi esterni come fonti di dati, strumenti e workflow (Model Context Protocol, 2026). È supportato da assistenti IA come Claude e ChatGPT e da strumenti di sviluppo come Visual Studio Code e Cursor.

L'architettura prevede tre partecipanti. L'host è l'applicazione di IA. Per ogni sistema a cui si collega, l'host crea un client. Il server è il programma che espone le funzioni di un sistema. Un server può offrire tools (funzioni che l'applicazione di IA può richiamare), resources (dati che forniscono contesto) e prompts (modelli riutilizzabili). I messaggi usano JSON-RPC 2.0. Un server locale comunica con il client tramite standard input e output, uno remoto tramite HTTP (panoramica dell'architettura MCP).

Per un back-office contano soprattutto i tools. Ogni tool ha un nome, una descrizione e un JSON Schema per i suoi input, e può dichiarare uno schema di output in modo che i risultati tornino come dati strutturati. Il client chiede al server quali tools esistono (tools/list) e ne richiama uno con degli argomenti (tools/call). La specifica stabilisce inoltre che i server devono validare tutti gli input dei tools, implementare controlli di accesso e limitare la frequenza delle chiamate, e che i client dovrebbero chiedere all'utente di confermare le operazioni sensibili e registrare l'uso dei tools a fini di audit (specifica MCP, Tools).

Come si rapportano le due cose

Una CLI e un server MCP sono due vie d'accesso alle stesse funzioni di business. «Mostra l'ordine 48213» dovrebbe essere una sola operazione nel sistema aziendale, raggiungibile come comando per gli agenti che eseguono comandi e come tool MCP per le applicazioni di IA che si collegano tramite il protocollo.

Ciò che conta è dove risiedono la logica e i diritti. Né la CLI né il server MCP dovrebbero contenere regole di business o decidere autonomamente che cosa può fare chi chiama. Entrambi passano la richiesta al sistema aziendale, che verifica identità, ruolo e permessi e restituisce il risultato. Se il server MCP di un fornitore ha una propria idea di chi può vedere quale cliente, vi ritrovate a mantenere due insiemi di regole, e questi finiranno per divergere.

In pratica, molti operatori inizieranno con la CLI perché è facile da testare: potete eseguire a mano lo stesso comando e vedere esattamente ciò che vede l'agente. Un server MCP remoto diventa utile quando diverse applicazioni di IA, o in seguito gli assistenti dei vostri clienti, hanno bisogno delle stesse funzioni senza installare nulla.

Una prima integrazione nel back-office di un operatore telco

Iniziate da una domanda ricorrente che ogni settimana costa tempo al vostro team, e limitate l'agente alla lettura. Un buon candidato sono i traslochi aperti: l'agente controlla ogni ordine di trasloco, confronta lo stato dell'ordine con il riscontro tecnico del team di rete ed elenca per il servizio clienti che cosa manca (una data confermata, un codice d'accesso all'edificio, un nuovo numero di serie dell'ONT). Un altro sono le attivazioni in fibra della prossima settimana con un ostacolo aperto.

L'ordine delle attività conta, quindi eccolo in passaggi:

1. Definite la domanda e la persona responsabile del risultato. Quella persona verifica l'elenco e decide che cosa succede dopo.
2. Elencate i comandi di lettura di cui l'agente ha bisogno: ricerca cliente, servizi di un cliente, stato dell'ordine, riscontro del provisioning, ticket aperti. Non concedete altro.
3. Create un'identità separata per l'agente con un ruolo in sola lettura, così le sue richieste si distinguono da quelle del collaboratore che lo esegue.
4. Fatelo girare accanto al processo manuale per alcune settimane e confrontate l'elenco dell'agente con ciò che ha trovato il team.
5. Solo dopo discutete le azioni di scrittura, una alla volta, ciascuna con una conferma esplicita da parte di una persona.

L'agente legge, la persona decide. Così gli errori restano poco costosi mentre scoprite dove i dati non sono aggiornati o dove due sistemi non concordano.

C'è un'altra decisione che va presa all'inizio. L'agente può inviare i dati restituiti al proprio fornitore di IA. Decidete quali campi restituiscono i comandi di lettura (al dispatcher servono l'indirizzo e l'appuntamento, all'agente non servono le coordinate bancarie del cliente) e scegliete un agente e una configurazione di hosting coerenti con la vostra policy sui dati.

Che cosa pretendere da qualsiasi fornitore

Che si tratti del vostro fornitore BSS, del vostro CRM o di uno strumento di gestione della rete, chiedete quanto segue prima di collegare un agente.

Autenticazione. Ogni richiesta porta con sé un'identità, per le persone e per gli agenti. Per i server MCP remoti la specifica sull'autorizzazione segue OAuth 2.1, e i server devono verificare che un token di accesso sia stato emesso per loro (specifica MCP, Authorization). Nel protocollo l'autorizzazione è facoltativa, quindi chiedete se è attivata.

Permessi circoscritti. Un agente riceve i diritti di cui il suo compito ha bisogno, e niente di più. La guida MCP raccomanda token di breve durata e scope con privilegi minimi suddivisi per strumento o funzionalità, verificati sul server a ogni chiamata (Understanding Authorization in MCP). Chiedete come viene configurato un agente in sola lettura, e che cosa succede quando prova a scrivere.

Registrazione. Ogni chiamata lascia una voce: quale agente, per conto di chi, quale comando, quali record, quando e con quale risultato. Chiedete di vedere la voce relativa a una richiesta rifiutata.

Limiti di frequenza. Un agente bloccato in un ciclo può interrogare il sistema degli ordini molto più velocemente di qualsiasi service desk. I limiti per agente proteggono il sistema e vi mostrano quando qualcosa non va.

Versionamento. Comandi e schemi dei tools cambiano. MCP stesso identifica le versioni del protocollo con una data, e la versione attuale è 2026-07-28 (versionamento MCP). Chiedete come il fornitore gestisce le versioni dei propri comandi, per quanto tempo uno deprecato continua a funzionare e dove vengono annunciate le modifiche.

Un test utile in qualsiasi demo: chiedete al fornitore di eseguire un comando che l'agente non è autorizzato a eseguire, poi di mostrarvi la voce di log che ha lasciato.

La CLI e il server MCP di METAVSHN

Gestiamo noi stessi un ISP (Ticinocom, dove i fondatori hanno alle spalle 30+ anni nelle telecomunicazioni), quindi abbiamo costruito queste interfacce per le domande che pone il nostro stesso service desk. La CLI e il server MCP di METAVSHN sono in accesso anticipato.

La CLI gira sul vostro computer e funziona con l'agente che la vostra azienda ha già approvato, qualsiasi agente in grado di eseguire comandi. Consulta clienti, servizi e policy. La ricerca di un comando e la sua descrizione funzionano offline, senza una richiesta al vostro BSS. I comandi sui dati restituiscono JSON, e ogni contratto di comando elenca gli input, il tipo di operazione e un'indicazione sui permessi. Il server MCP espone le stesse funzioni alle applicazioni di IA che parlano MCP.

Ogni richiesta, dalla CLI o dal server MCP, viene verificata da METAVSHN rispetto a identità, ruolo e permessi. Le indicazioni sui permessi dicono all'agente di che cosa avrà probabilmente bisogno un'operazione. Di per sé non concedono nulla. Cancellare qualcosa o inviare qualcosa all'esterno richiede una conferma esplicita, e un dry run mostra la richiesta prima che venga inviato qualcosa.

Se volete provare una prima integrazione in sola lettura sui vostri dati di clienti e ordini, diteci quale agente usa il vostro team e vi aggiungeremo al gruppo dell'accesso anticipato: la CLI e il server MCP di METAVSHN.

Fonti

Tutte le fonti consultate il 31 ottobre 2026.

1. Model Context Protocol, «What is the Model Context Protocol (MCP)?», documentazione per la versione del protocollo 2026-07-28, luglio 2026. modelcontextprotocol.io
2. Model Context Protocol, «Architecture overview», versione del protocollo 2026-07-28, luglio 2026. modelcontextprotocol.io
3. Model Context Protocol, «Tools», versione della specifica 2026-07-28, luglio 2026. modelcontextprotocol.io
4. Model Context Protocol, «Authorization», versione della specifica 2026-07-28, luglio 2026. modelcontextprotocol.io
5. Model Context Protocol, «Understanding Authorization in MCP», luglio 2026. modelcontextprotocol.io
6. Model Context Protocol, «Versioning», versione attuale 2026-07-28. modelcontextprotocol.io