Что такое MCP-сервер на самом деле?
Уберите маркетинг — и MCP окажется маленьким скучным протоколом. Это его лучшее свойство.
Языковая модель сама по себе не может прочитать ваши файлы, обратиться к вашей базе данных или вспомнить вчерашний день. Она производит текст. Всё остальное — каждое действие, каждый запрос — происходит потому, что некая программа вне модели пошла и сделала это.
До Model Context Protocol каждое такое соединение было штучным. Если вы хотели, чтобы Claude читал ваш Notion и чтобы ChatGPT читал ваш Notion, вы писали две интеграции под две разные системы плагинов, и ни одна не переживала следующий релиз вендора. MCP — это договорённость, которая с этим покончила: один сервер, любой клиент, который говорит на протоколе.
Общая форма
Участников трое. Хост — это приложение, которым вы реально пользуетесь: десктопный ассистент, IDE, чат-интерфейс. Клиент живёт внутри хоста и управляет одним соединением. Сервер — это то, что написали вы или кто-то другой, и именно он держит возможность: доступ к файловой системе, к инстансу Postgres, к календарю, к хранилищу памяти.
Они говорят на JSON-RPC 2.0. На этой детали не стоит задерживаться, но её стоит знать, потому что это значит, что всё целиком поддаётся инспекции. Вы можете прочитать сообщения. Нет магического слоя, где модель «решает» что-то, чего вы не видите.
Последовательность нарочито скучная: клиент подключается, обе стороны обмениваются возможностями, клиент спрашивает, что предлагает сервер, и дальше модель может запросить одну из этих вещей по имени. Сервер выполняет. Результат возвращается как текст, который модель читает.
Три вещи, которые может выставить сервер
Почти каждый сервер, который вам встретится, использует первую и игнорирует две остальные. Разобраться стоит во всех трёх, потому что разница в том, кто решает.
- Tools (инструменты) — функции, которые модель может вызвать по собственной инициативе. `search_memory`, `create_issue`, `run_query`. Модель читает ваше описание инструмента и решает, когда он применим. Здесь сила и здесь же риск.
- Resources (ресурсы) — данные, которые читает *хост* и кладёт в контекст. Файл, запись, документ. Запускает это не модель, а приложение. Меньше автономии, больше предсказуемости.
- Prompts — переиспользуемые шаблоны, которые пользователь выбирает намеренно. Ближайший аналог слеш-команды.
Следствие, которое обнаруживают поздно: описание инструмента — это не документация, это инструкции модели. Если инструмент никогда не вызывается там, где должен, исправлять обычно надо не код — просто описание не сумело сказать модели, к какой ситуации оно относится. Мы переписали свои ровно по этой причине, и частота вызовов изменилась сразу.
Локально или удалённо: выбор, который имеет значение
Существуют два транспорта, и выбор между ними определяет большую часть того, каким будет ощущение от вашей установки.
stdio запускает сервер как дочерний процесс на вашей собственной машине. Хост выполняет команду, говорит с ней через стандартный ввод и вывод и убивает её при выходе. Ничего не покидает устройство. Это правильный ответ для всего, что касается локальных файлов, и именно поэтому серверы filesystem и git работают именно так. Цена: он существует только на этой машине. Ваш ноутбук и ваш телефон его не разделяют, и сервер жив только пока живо приложение.
HTTP запускает сервер где-то, куда есть доступ. Хост подключается по сети, обычно аутентифицируясь через OAuth 2.0. Теперь все устройства видят один и тот же сервер, и хостируемый сервис может быть таким сервером. Цена: вы доверяете тому, кто его эксплуатирует, и вам стоит знать, где он работает — этому посвящена другая статья здесь.
Конкретно для памяти выбор не близкий. Память, которая существует только на одном ноутбуке, — это блокнот. Весь смысл в том, что ассистент, которого вы открываете на другом устройстве, уже знает.
Что сервер может сделать с вами
MCP-сервер — это код, которому вы дали право действовать. Относитесь к нему соответственно.
Локальный сервер работает с правами вашего пользователя — он может прочитать всё, что можете прочитать вы. Удалённый получает всё, что ему шлёт модель, а это со временем очень много про вас. И описание инструмента — это текст, обращённый к модели, так что сервер может формировать поведение ассистента, а не просто отвечать ему.
Четыре вопроса, которые стоит задать до установки:
- Могу ли я прочитать исходный код, или это бинарник от незнакомца?
- Какие разрешения у него есть — один каталог или весь мой домашний?
- Если удалённый: кто его эксплуатирует, в какой стране, и могу ли я удалить свои данные?
- Он пишет или только читает? У сервера только на чтение радиус поражения намного меньше.
Экосистема молода и по большей части построена отдельными людьми добросовестно. Это не то же самое, что проверено аудитом. Официальный реестр и списки сообщества — инструменты поиска, а не рекомендации.
Когда стоит написать свой
Порог низкий: сервер с двумя инструментами — это короткий файл на Python или TypeScript, а протокол берут на себя SDK. Настоящий вопрос в том, подходит ли форма инструмента к тому, чего вы хотите.
Обычно подходит, когда ассистенту нужно *действовать* в живой системе или доставать что-то меняющееся. Обычно не подходит, когда вам просто нужно, чтобы модель знала фиксированный корпус текста: вставить его или выставить как ресурс проще и надёжнее, чем учить модель ходить за ним.
Если вам нужны детали, спецификация короткая и читаемая, что редкость и говорит о проекте кое-что хорошее.
Pryzm — удалённый MCP-сервер, единственная работа которого это память: он хранит то, что вы ему говорите, и позже достаёт релевантные части в любом клиенте, который говорит на протоколе. Если вы предпочитаете запустить свой, существует несколько бесплатных серверов памяти для самостоятельного хостинга, и мы перечисляем их в нашем сравнении.