- Un agente AI ha bisogno di un server MCP dedicato per inviare SMS?
- Come si presenta davvero la definizione del tool-schema?
- Come eviti che un agente invii 10.000 SMS per sbaglio?
- Qual è la differenza tra un rate limit e un loop di conferma?
- Cosa non deve mai essere consentito all'agente senza supervisione?
- Dare a un agente LLM la capacità di inviare SMS è a una sola funzione tool-call REST di distanza per un singolo provider: non serve un server MCP dedicato.
- Il panorama 2026 ha diversi server MCP specifici per SMS (Ozeki, Infobip, Sendly e altri), ma i report di produzione descrivono i setup MCP multi-server come gonfi di tool e difficili da delimitare.
- Il vero rischio è l'autonomia, non il trasporto: un agente può ripetere in loop un invio bulk errato in pochi secondi, quindi un tetto di rate e un gate di conferma umana oltre una soglia di destinatari contano più del protocollo che porta la chiamata.
- L'endpoint di invio flat di SMSRoute, i delivery receipt per messaggio e il prezzo mostrato prima dell'invio lo rendono semplice da wrappare come una sola funzione tool con un tetto di costo hard per chiamata.
Un agente AI ha bisogno di un server MCP dedicato per inviare SMS?
No, un agente AI non ha bisogno di un server MCP dedicato per un singolo provider SMS; una funzione tool REST con un endpoint e un header di auth basta.
Entro il 2026 Ozeki, Infobip, Sendly e Mobile Text Alerts pubblicano server MCP SMS dedicati, quindi il pattern sembra obbligatorio. I report di produzione descrivono i setup MCP multi-server come gonfi di tool con overhead di scoping. MCP giustifica l'overhead quando un agente serve molti tool o provider dietro un protocollo condiviso. Per una singola SMS API, MCP aggiunge soprattutto superficie di processo che non serve. Preferisci la chiamata tool REST diretta e tieni lo stack abbastanza piccolo da auditare in un solo posto.
- Integrazione minima vitale
- una funzione tool REST, un endpoint, un header di auth
- Quando MCP si guadagna il posto
- un agente serve molti tool o provider dietro un protocollo condiviso
- Panorama 2026
- Server MCP specifici per SMS ora pubblicati da Ozeki, Infobip, Sendly e altri
- Lettura della community su MCP multi-server
- bloat di tool e overhead di scoping segnalati in produzione
Come appare davvero la definizione dello schema tool?
Uno schema tool chiamato send_sms elenca numero destinatario, corpo del messaggio e label mittente opzionale come unici input che il modello può compilare, con un breve oggetto status restituito dopo l'esecuzione dell'handler.
Il modello non tocca mai le credenziali o il client HTTP. Propone la chiamata; il tuo runtime valida gli args contro i guardrail che hai codificato, fa POST al provider e restituisce solo il risultato dichiarato. Quel confine è il punto: lo schema è il contratto che l'agente vede, mentre la chiave segreta e la logica di rate restano nel codice che controlli. Se lo schema diverge da ciò che l'handler applica davvero, l'agente continuerà a chiamare una menzogna.
Come impedisci a un agente di inviare 10.000 SMS per errore?
Metti guardrail hard nel codice della funzione tool, non nel system prompt, perché un'istruzione di prompt non è un controllo tecnico e un agente può essere convinto o loopato oltre.
Il punto è la velocità: una volta che l'agente controlla il loop di invio, una lista sbagliata o una tempesta di retry svuota un saldo prima che qualcuno se ne accorga. Regola decisionale: il tuo runtime valida ogni chiamata proposta contro il tetto di rate, il cap di costo di sessione e il gate di conferma prima che qualsiasi richiesta arrivi al provider. Quei controlli stanno nel codice che auditi, non nel testo rivolto al modello. La timeline sopra indica l'ordine; il punto in prosa è che il rifiuto avviene prima del wire, ogni volta.
- L'agente propone un inviolista destinatari e messaggio redatti dal modello
- Esegue il check dei guardrailconteggio destinatari vs soglia bulk, costo vs cap di sessione
- Conferma se oltre la soglial'esecuzione si blocca finché un umano non approva, non opzionale
- Esegui e registrauna chiamata API per ogni invio approvato, receipt registrato per audit
Qual è la differenza tra un rate limit e un loop di conferma?
Un rate limit è un tetto meccanico che ferma un loop fuori controllo o una tempesta di retry; un loop di conferma è un punto decisionale umano inserito prima di un'azione bulk irreversibile.
Non si sostituiscono a vicenda. Un rate limit da solo lascia comunque passare una singola chiamata bulk errata sotto il tetto. Un gate di conferma da solo non ferma un loop di chiamate ripetute veloci. Usali entrambi. Cabla il tetto nell'handler del tool e richiedi un sì umano prima di qualsiasi bulk che superi la soglia di destinatari, così un controllo copre ciò che manca all'altro.
| Controllo | Cosa ferma | Dove vive |
|---|---|---|
| Rate limit | Loop fuori controllo, tempeste di retry | Applicato nella funzione tool prima della chiamata |
| Gate di conferma | Un invio massivo errato uscito in modo irreversibile | Human-in-loop, oltre una soglia impostata di destinatari o costo |
| Tetto di costo di sessione | Sforamento budget da chiamate legittime ripetute | Tracciato cumulativamente nella sessione dell'agente |
Cosa non deve mai essere consentito all'agente senza supervisione?
Non lasciarlo mai eseguire senza supervisione invii massivi oltre la soglia impostata, messaggi a liste appena generate o non verificate, marketing senza opt-out controllato, o contenuti di frode, phishing, molestie o impersonificazione rifiutati dalla policy di uso accettabile di SMSRoute. Sono hard stop che applichi nel tool handler prima che qualsiasi chiamata al provider esca dal tuo processo.
Un agente che redige e propone va bene. Un agente che esegue da solo invii massivi irreversibili è il rischio reale. Metti il controllo soglia, il gate di verifica lista, il requisito opt-out e il filtro contenuti AUP nel codice che rifiuta la chiamata e restituisce un errore chiaro. Il runtime decide; il modello propone soltanto.
{
"name": "send_sms",
"description": "Send one SMS. Blocks and requires human confirmation above 5 recipients.",
"parameters": {
"to": "string, E.164 phone number",
"message": "string, max 160 characters",
"sender_id": "string, optional"
}
}
# guardrail enforced INSIDE the tool function, not the prompt:
if len(recipients) > 5 or session_cost + estimate(recipients) > SESSION_COST_CAP:
return require_human_confirmation(recipients, estimate(recipients))
# the actual call, once approved:
curl -X POST https://api.smsroute.cc/sms/send \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"to": "+14155550123", "from": "INFO", "message": "Your code is 482913"}'Domande frequenti
Devo usare MCP per dare a un agente la capacità di inviare SMS?
No. MCP è uno dei tanti pattern di integrazione, utile quando molti tool o provider condividono un'unica superficie di protocollo. Una funzione tool REST definita direttamente funziona già oggi per un singolo provider, con meno parti mobili da auditare. Il tool-calling nativo negli SDK Claude, OpenAI e open-source accetta quello schema di funzione senza un host MCP; aggiungi MCP solo quando standardizzi già molti provider dietro un unico protocollo.
Cosa succede se la chiamata tool dell'agente fallisce o va in timeout?
Tratta una chiamata tool in timeout o fallita come qualsiasi altro fallimento tool: blocca i retry ciechi dell'agente. Allega un reference ID generato dal client così un retry non può fare doppio invio, e registra il fallimento accanto agli invii riusciti. In timeout dopo che il provider ha accettato la richiesta, interroga lo stato per message ID invece di reinviare; i messaggi falliti vengono accreditati automaticamente.
L'agente può leggere i delivery receipt?
Sì. Concedi all'agente un secondo tool in sola lettura che verifica lo stato di consegna di un messaggio; è una classe di rischio diversa da una funzione di invio. L'accesso in lettura ampio ai receipt è ragionevole, l'accesso illimitato all'invio no. Lo stato torna in tempo reale tramite webhook DLR e il log della dashboard, così l'agente fa polling o riceve aggiornamenti senza privilegi di scrittura.
SMSRoute pubblica tooling ufficiale per agenti AI?
No. SMSRoute non pubblica un MCP server ufficiale né un SDK specifico per agenti. La superficie core è una semplice REST API con esempi di codice in Python, PHP, Go e Node su GitHub (SMSRoute-cc), più bind SMPP per mittenti ad alto volume, deliberatamente la superficie minima che il layer di tool-calling di un agente deve wrappare con o senza MCP davanti. Il tuo handler recupera anche lo stato di consegna in tempo reale tramite webhook DLR dopo ogni invio.
Browser aperto, numero digitato, prezzo mostrato prima di inviare - da $0.004 per messaggio, US $0.0125, pagato in crypto.
Provalo con crediti di testregistrazione solo email · BTC, ETH, USDT, XMR, LTC, SOLSecondo AGCOM, l'invio di messaggi SMS a scopo commerciale richiede il consenso preventivo espresso dal destinatario. Questo non costituisce consulenza legale.