StandardToolV0 — одно описание инструмента вместо пяти обёрток
Саммари
Один и тот же инструмент приходится переписывать по меньшей мере трижды: tool() из AI SDK, registerTool из MCP SDK, defineTool из Genkit. Функции остаются прежними — меняется только обёртка, и библиотека, желающая поставлять инструменты, вынуждена выбрать один фреймворк вместе со всеми его потребителями. Статья разбирает предложение StandardToolV0: типизированный объект без рантайма, который описывает инструмент один раз и переносится в любой фреймворк через маленький адаптер.
Из этого следует: инструмент не обязан жить внутри фреймворка. Оформленный обычным объектом, он остаётся библиотечным кодом, который можно вызвать, протестировать и задокументировать без установки чужого фреймворка, а адаптер к MCP SDK или AI SDK пишется в несколько строк.
На практике для Revit MCP это прямо применимо: набор инструментов Revit-сервера логично описать один раз в своём формате, а конкретную MCP-регистрацию делать тонким слоем. Бонус — те же объекты годятся для документации студии и для CLI-обёртки над тем же кодом.
Важный нюанс: MCP SDK 1.31 принимает только Zod, поэтому «переносимость» сейчас достигается на уровне собственного описания, а не на уровне официальной поддержки в MCP. Это стоит проговорить отдельно, иначе ожидания курса будут завышены.
Второй нюанс: у LangChain в таблице нет схемы выхода, а у Genkit и LangChain функция передаётся позиционным аргументом. Именно такие мелочи ломают автоматический перенос, и наличие промежуточного типа как раз их и изолирует.
Третий нюанс: автор честно называет проект предложением с одним мейнтейнером и ссылается на XKCD 927. Для учебного материала это нормально — как пример направления, но не как готовая зависимость.