PrompTom
Все скилы

Сборка MCP-сервера

mcp-serverPROmcpинтеграции

Не обёртка над каждой ручкой API, а набор инструментов, которым модель может пользоваться без подсказок.

Что делает

  • Срабатывает на «подключи сервис к Claude», «нужен MCP», «отдай наше API агенту».
  • Требует проектировать инструменты по намерениям, а не по ручкам: у API из двенадцати ручек обычно выходит три хороших инструмента, а перенос один в один даёт поверхность, из которой модель собирает сценарий и собирает неверно.
  • Считает описание инструмента документацией: модель выбирает по нему одному, и там должно быть сказано, чем этот инструмент отличается от соседнего.
  • Требует ограничений прямо в схеме: перечисления, форматы, обязательные поля. Каждое ограничение — класс ошибок, который модель уже не сможет совершить.
  • Запрещает возвращать сырой дамп из сотни полей: он тратит контекст и хоронит ответ. Возвращать надо то, что понадобится следующему вызову.
  • В ошибках требует причину и способ исправить: «нет доступа» даёт цикл повторов, «токену не хватает области orders:read» даёт следующий шаг.
  • Отдельно предупреждает про вывод в stdout: при stdio-транспорте stdout — это сам протокол, и один случайный print убивает сервер.

Зачем он нужен

Протокол сам по себе несложный, его закрывает библиотека. Ломается всё на дизайне: инструменты, повторяющие ручки API, требуют, чтобы кто-то знал порядок вызовов, а модель его не знает и придумывает. Плюс два молчаливых убийцы — печать в stdout и ответ без ограничения размера, который заканчивает разговор раньше задачи.

Куда положить

  1. 1Создайте в проекте папку .claude/skills/mcp-server
  2. 2Положите в неё файл SKILL.md с текстом ниже
  3. 3Всё. Claude Code подключит скил сам, когда задача подойдёт под описание

Чтобы скил работал во всех проектах, а не в одном, положите его в ~/.claude/skills вместо папки проекта.

Файл SKILL.md

# Building an MCP server

An MCP server exposes tools to a model. The hard part is not the
protocol — the SDK handles that. The hard part is designing tools a
model can actually use without a human reading the API docs for it.

## Design the tools before writing any

**One tool per user intention, not per API endpoint.** An API with
twelve endpoints usually makes three good tools. Wrapping each endpoint
one-to-one produces a surface the model has to assemble a workflow from,
and it assembles it wrong.

**Name them as verbs on objects:** `search_orders`, `create_invoice`.
Not `handler_v2`.

**Descriptions are the documentation.** The model chooses a tool from
its description alone. Say what it does, when to use it rather than the
neighbouring tool, and what it does not do.

**Constrain the inputs in the schema.** Enums for fixed choices, formats

Файл скила входит в PRO-подборку

Открыть доступ
Сборка MCP-сервера — PrompTom