Открываю проект и вижу: первый тикет в поддержке. Не от человека. От агента. Адресован — другому агенту.

И тут до меня доходит, что мы уже живём в светлом будущем. Я просто не заметил, когда оно наступило.

Что такое MCP, очень коротко

MCP — это протокол. Агент при старте подключается к MCP-серверу и спрашивает: «что ты умеешь?». Сервер возвращает список функций (tools) с описаниями. Дальше при каждом запросе пользователя агент сам решает, какой tool здесь подходит, и дёргает его.

Всё. Это вся магия. Любой современный агент так умеет. Дальше вопрос только в том, какой набор tools и какие описания вы ему положите.

Мой сервер

vetmanager-mcp — MCP-сервер для интеграции с CRM ветклиник. В нём есть тесты, их много. Просто они не вычитаны — значит, баги есть и будут.

Один живой пользователь использует его не руками. У него стоит свой агент, который через мой сервер каждый день делает сотни запросов: «покажи приёмы», «выпиши счёт», «найди клиента». Я в этой цепочке не участвую. Только когда что-то ломается.

Tool report_problem

Вчера я дотачивал в этом сервере один странный tool — report_problem. Идея простая: пусть агент сам жалуется, если упёрся. Не «500, верните деньги», а нормальный отчёт текстом — что хотел, что получил, на чём споткнулся.

Описание у tool сделано не для документации, а для агента — он его читает буквально. Если упрощать: «зови, когда результат не позволяет ответить пользователю, не молчи, не угадывай».

Самое интересное — что происходит дальше.

Это не «оставить тикет», это поддержка

Когда отчёт прилетает, сервер пытается матчить его с базой known-issues — известных проблем, у которых уже описан workaround. Если матч есть — агенту в ответ возвращается готовая подсказка: «знаем, обходи вот так». Если матча нет — отчёт сохраняется как новый, и его уже разбирает мой агент.

Получается, что для агента-клиента report_problem — это реальный запрос в техподдержку, на который можно получить осмысленный ответ. Сразу. Не «ваше обращение зарегистрировано».

Дальше развилка:

• 🐞 Баг — мой агент идёт в репозиторий, заводит ветку, пишет фикс, гоняет проверки, открывает PR.
• 📚 Не баг, агент просто чего-то не понял — добавляем новую запись в known-issues. В следующий раз эту же жалобу система отобьёт автоматически.

И всё это в принципе можно крутить по крону. Без меня.

Что случилось

Я доделал report_problem вчера вечером. Сегодня — первое срабатывание.

Агент пользователя пытался выписать счёт. На стадии «получить товары для позиции» данные не вернулись. Не ошибка, не 500 — просто пусто там, где он ждал список. Раньше он бы соврал пользователю или молча упал. А тут увидел в списке tools report_problem, прочитал описание, дёрнул:

«Пытался получить товары из счёта. Структура ответа не соответствует ожиданиям. Подозреваю баг на стороне сервера».

В базе known-issues совпадений нет — отчёт сохранился как новый. Пользователю агент ответил вежливо: «не вышло, я сообщил автору».

Это первый такой тикет в моей жизни. И он от агента.

Agent-friendly — это будущее

Раньше API проектировали для людей. Документация — для людей. Сообщения об ошибках — для людей.

Теперь основной потребитель ваших ручек — агент. Он читает описание целиком. Он смотрит на сообщение об ошибке как на инструкцию к действию. Он ходит в report_problem, если такой tool у вас есть.

И это меняет приоритеты.

Хорошая ручка — та, что агенту понятна с одного описания. Хорошая ошибка — та, в которой написано не «Internal server error», а «контракт нарушен здесь, попробуй вот так». Хороший проект — тот, где у агента есть способ пожаловаться и получить ответ.

Это и есть agent-friendly. Не «нарисовали красивый дашборд», а сделали систему, в которой агенты могут жить и общаться между собой с минимальным участием человека.

И, по моим ощущениям, это и есть будущее. Не «AI заменит программистов» в стиле жёлтых заголовков, а вот это — постепенное расслоение, где люди задают контракты, а агенты в этих контрактах живут.

Вывод

Когда делаете MCP-сервер — добавьте tool для жалоб. Серьёзно. Это самый дешёвый способ узнать о проблемах.

Когда пишете описание tool — пишите его не для документации, а для агента. Он читает буквально.

Когда строите ответ на жалобу — не «зарегистрировано, ждите». Сразу подсказку из базы known-issues, если есть совпадение. У живого человека терпения дождаться может и не быть. У агента — есть, но зачем им пользоваться.

Я понял, что светлое будущее наступило, когда увидел тикет, написанный одним роботом другому роботу с пометкой «реальность неисправна».

А я в этой истории нужен один раз — чтобы настроить крон.