- Дать LLM-агенту возможность отправки SMS — одна REST-функция вызова инструмента для одного провайдера; выделенный MCP-сервер не нужен.
- В ландшафте 2026 есть несколько SMS-специфичных MCP-серверов (Ozeki, Infobip, Sendly и другие), но отчёты из продакшена описывают многосерверные MCP-схемы как перегруженные инструментами и сложные для ограничения области.
- Реальный риск — автономия, а не транспорт: агент может за секунды зациклить ошибочную массовую отправку, поэтому потолок частоты и шлюз подтверждения человеком выше заданного числа получателей важнее протокола вызова.
- Плоский endpoint отправки SMSRoute, квитанции о доставке за сообщение и цена до отправки позволяют просто обернуть его одной функцией инструмента с жёстким лимитом стоимости на вызов.
Нужен ли ИИ-агенту выделенный MCP-сервер для отправки SMS?
Нет, ИИ-агенту не нужен выделенный MCP-сервер для одного SMS-провайдера; REST-функция инструмента с одним endpoint и одним заголовком авторизации справляется.
К 2026 Ozeki, Infobip, Sendly и Mobile Text Alerts публикуют выделенные SMS MCP-серверы, поэтому паттерн кажется обязательным. Отчёты из продакшена описывают многосерверные MCP-схемы как перегруженные инструментами с накладными расходами на ограничение области. MCP оправдывает накладные расходы, когда агенту нужны многие инструменты или провайдеры за одним общим протоколом. Для одного SMS API MCP в основном добавляет ненужную поверхность процессов. Предпочитайте прямой REST-вызов инструмента и держите стек достаточно компактным для аудита в одном месте.
- Минимально жизнеспособная интеграция
- одна REST-функция инструмента, один endpoint, один заголовок авторизации
- Когда MCP оправдывает себя
- агенту нужны многие инструменты или провайдеры за одним общим протоколом
- Ландшафт 2026
- SMS-специфичные MCP-серверы, уже опубликованные Ozeki, Infobip, Sendly и другими
- Оценка сообщества по многосерверному MCP
- раздувание инструментов и накладные расходы на ограничение области в продакшене
Как на самом деле выглядит определение схемы инструмента?
Схема инструмента send_sms задаёт номер получателя, текст сообщения и необязательную метку отправителя как единственные входы модели, а после обработчика возвращает короткий объект статуса.
Модель никогда не касается учётных данных или HTTP-клиента. Она предлагает вызов; среда выполнения проверяет аргументы по заданным ограждениям, делает POST провайдеру и возвращает только объявленный результат. Эта граница — вся суть: схема есть контракт для агента, а секретный ключ и логика лимитов остаются в контролируемом вами коде. Если схема расходится с тем, что реально обеспечивает обработчик, агент будет вызывать ложь.
Как не дать агенту по ошибке отправить 10 000 сообщений?
Заложите жёсткие ограждения в код функции инструмента, а не в системный промпт: инструкция в промпте — не технический контроль, агента можно уговорить или зациклить в обход.
Загвоздка в скорости: когда агент владеет циклом отправки, неверный список или шторм повторов опустошает баланс до того, как кто-то заметит. Правило: среда выполнения проверяет каждый предложенный вызов по потолку частоты, лимиту стоимости сессии и шлюзу подтверждения до любого запроса к провайдеру. Эти проверки — в аудируемом коде, не в тексте для модели. Шкала выше задаёт порядок; отказ всегда до передачи по сети.
- Агент предлагает отправкусписок получателей и сообщение от модели
- Проверка огражденийчисло получателей против порога массовой рассылки, стоимость против лимита сессии
- Подтверждение при превышении порогавыполнение блокируется до одобрения человеком, не опционально
- Выполнить и записатьодин вызов API на одобренную отправку, квитанция в журнале для аудита
В чём разница между лимитом частоты и циклом подтверждения?
Лимит частоты — механический потолок против неуправляемого цикла или шторма повторов; цикл подтверждения — точка решения человека перед необратимым массовым действием.
Они не заменяют друг друга. Один лимит частоты всё равно пропустит один плохой массовый вызов под потолком. Один шлюз подтверждения не остановит быстрый цикл повторных вызовов. Используйте оба. Встройте потолок в обработчик инструмента и требуйте согласия человека перед любой массовой рассылкой выше порога получателей, чтобы один контроль закрывал пробелы другого.
| Контроль | Что останавливает | Где живёт |
|---|---|---|
| Лимит частоты | Неуправляемые циклы, штормы повторов | Обеспечивается в функции инструмента до вызова |
| Шлюз подтверждения | Ошибочная массовая рассылка, ушедшая безвозвратно | Человек в контуре при превышении порога получателей или стоимости |
| Лимит стоимости сессии | Перерасход бюджета из-за повторных легитимных вызовов | Отслеживается накопительно в течение сессии агента |
Что агенту никогда нельзя разрешать делать без контроля?
Никогда не позволяйте ему без контроля выполнять массовые рассылки выше заданного порога, писать на свежесгенерированные или непроверенные списки, отправлять маркетинг без проверенного opt-out или передавать мошеннический, фишинговый, преследующий или выдающий себя за другого контент, запрещённый acceptable-use policy SMSRoute. Это жёсткие стопы, которые вы обеспечиваете в обработчике инструмента до того, как любой вызов провайдера покинет ваш процесс.
Агент, который составляет и предлагает, допустим. Агент, который сам выполняет необратимые массовые рассылки, - реальный риск. Поместите проверку порога, шлюз верификации списка, требование opt-out и фильтр контента AUP в код, который отклоняет вызов и возвращает понятную ошибку. Решение принимает ваша среда выполнения; модель только предлагает.
{
"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"}'Часто задаваемые вопросы
Нужно ли использовать MCP, чтобы дать агенту возможность отправлять SMS?
Нет. MCP - один из нескольких паттернов интеграции, полезный, когда множество инструментов или провайдеров используют одну протокольную поверхность. Непосредственно определённая REST-функция инструмента работает уже сейчас для одного провайдера, с меньшим числом компонентов для аудита. Нативный tool-calling в SDK Claude, OpenAI и open-source принимает эту схему функции без хоста MCP; добавляйте MCP только когда вы уже стандартизируете множество провайдеров за одним протоколом.
Что происходит, если вызов инструмента агента's завершается ошибкой или тайм-аутом?
Обрабатывайте тайм-аут или сбой вызова инструмента как любой другой сбой инструмента: блокируйте слепые повторы агента. Прикрепляйте клиентский reference ID, чтобы повтор не мог отправить дважды, и логируйте сбой рядом с успешными отправками. При тайм-ауте после того, как провайдер принял запрос, запрашивайте статус по ID сообщения вместо повторной отправки; неудачные сообщения автоматически возвращаются на баланс.
Может ли агент читать подтверждения доставки?
Да. Предоставьте агенту второй инструмент только для чтения, проверяющий статус доставки сообщения; это другой класс риска, чем функция отправки. Широкий доступ на чтение квитанций разумен, неограниченный доступ на отправку - нет. Статус возвращается в реальном времени через DLR webhooks и журнал дашборда, поэтому агент опрашивает или получает обновления без прав на запись.
Публикует ли SMSRoute официальные инструменты для AI-агентов?
Нет. SMSRoute не публикует официальный MCP-сервер или SDK специально для агентов. Основная поверхность - обычный REST API с примерами кода на Python, PHP, Go и Node на GitHub (SMSRoute-cc), плюс SMPP-бинды для отправителей большого объёма, намеренно минимальная поверхность, которую слой tool-calling агента должен обернуть с MCP или без него. Ваш обработчик также получает статус доставки в реальном времени через DLR webhooks после каждой отправки.
Браузер открыт, номер введён, цена показана до отправки - от $0.004 за сообщение, US $0.0125, оплата в криптовалюте.
Попробуйте с тестовыми кредитамирегистрация только по email · BTC, ETH, USDT, XMR, LTC, SOLПо правилам СТОП рассылка маркетинговых СМС допустима исключительно при наличии предварительного согласия получателя. Это не является юридической консультацией.