Ты знаешь три примитива. Осталось понять механику, которая всё связывает: как модель выбирает, какой инструмент вызвать.
Модель видит описания, а не код
Когда хост подключает серверы, он передаёт модели список доступных инструментов — для каждого только имя, описание и схему входа. Реализацию модель не видит и видеть не должна. Дальше всё просто: ты пишешь задачу обычным языком, а модель сопоставляет её с описаниями и решает, что подходит.
Поэтому описание — это не документация «на потом», а рабочий интерфейс выбора. Сравни два инструмента трекера:
nayti_zadachu — «поиск»
nayti_zadachu — «Находит задачи по тексту, исполнителю и статусу. Используй, когда пользователь спрашивает про существующие задачи.»
С первым описанием модель будет гадать. Со вторым — уверенно выберет его, когда ты спросишь «какие задачи висят на Петрове?».
Почему описание важнее кода
Код инструмента может быть идеальным, но если описание размытое или два инструмента описаны похоже — модель промахнётся: вызовет не тот, перепутает параметры или не вызовет ничего. Хорошее описание убирает двусмысленность лучше любой оптимизации.
Порепетируй
Ниже — диалог, где нужно рассуждать: хватит ли текста, нужен ли вообще инструмент и как описание влияет на выбор.
Ты подключил к Claude MCP-сервер вашего трекера задач. Сейчас разберём, как Claude решает, что вызывать — и нужен ли вызов вообще.
Claude
Ты просишь: «Объясни, чем tool отличается от resource в MCP». Мне тянуться к инструменту трекера?