Что такое MCP простыми словами

MCP это стандарт, по которому модель получает доступ к инструментам: поиску, чтению файлов, вызову API. Разберём без жаргона и покажем конфиг.

Зачем модели вообще нужны инструменты

Языковая модель умеет ровно одно: генерировать текст. Она не открывает сайты, не читает файлы, не ходит в API. Всё, что она «знает», зафиксировано весами на дату обучения, а живых данных у неё нет. Чтобы модель могла что-то сделать, а не только рассуждать по памяти - найти страницу в вебе, прочитать документ, дёрнуть внешний сервис - ей дают инструменты: функции, которые она может вызвать, а результат вернётся обратно в её контекст.

Загвоздка в том, что до недавнего времени каждый прикручивал такие инструменты по-своему. Один формат вызова под одного агента, другой под другого, свой клей под каждую связку «модель - инструмент». MCP появился, чтобы убрать этот зоопарк.

Что такое MCP

MCP (Model Context Protocol) - это открытый стандарт, который описывает, как подключать инструменты и данные к языковой модели единым способом. Спецификация опубликована на modelcontextprotocol.io. Идея простая: инструмент один раз описывает по общему протоколу, что он умеет, и после этого его понимает любой MCP-совместимый клиент. Писать интеграцию заново под каждую программу не нужно.

По сути MCP для инструментов - это то же, чем USB-C стал для железа: общий разъём. Раньше под каждое устройство был свой кабель, теперь один порт для всего.

Две стороны: клиент (хост) и сервер

В MCP всегда две роли:

• MCP-клиент, он же хост - программа, в которой живёт модель и которая умеет вызывать инструменты: LM Studio, Claude Desktop, Cursor, Continue.dev.
• MCP-сервер - отдельная программа, которая что-то умеет и выставляет это как набор инструментов. Сервер может оборачивать базу данных, файловую систему, внешний API или веб-поиск. grounder - это MCP-сервер для поиска и чтения веба.

Слово «сервер» здесь не значит «где-то в облаке». Часто это обычный локальный процесс на вашей же машине (об этом ниже). А один клиент может держать сразу несколько серверов - поиск, файлы, git - и модель видит все их инструменты разом.

Как проходит вызов

Поток всегда один и тот же:

1. При подключении клиент спрашивает у сервера список инструментов с их параметрами и показывает их модели.
2. Модель по ходу диалога сама решает, что ей нужен инструмент, и формирует вызов с аргументами (например, поисковый запрос).
3. Клиент передаёт этот вызов серверу.
4. Сервер делает работу - ищет, читает страницу, ходит в API - и возвращает результат.
5. Клиент вкладывает результат обратно в контекст модели, и она продолжает ответ уже с этими данными.

Ключевой момент: инструмент вызывает именно модель, а не жёстко зашитый код. Вы описываете, что доступно, а когда этим воспользоваться, решает она.

Транспорт: локальный процесс или удалённый сервер

MCP не привязан к одному способу связи между клиентом и сервером. На практике их два:

• Локальный процесс (stdio). Клиент сам запускает сервер как дочерний процесс и общается с ним через стандартный ввод-вывод. Именно так подключается grounder: тонкий клиент grounder-mcp запускается через uvx, живёт локально и просто передаёт вызовы на наши серверы. Ни браузера, ни скрапера у вас на машине не поднимается.
• Удалённый сервер. Сервер работает где-то по сети, а клиент ходит к нему по HTTP. Так подключают общие серверы, которые не нужно ставить локально.

Что возвращает MCP-сервер веб-поиска

У сервера веб-поиска инструменты - это поиск и чтение страниц. У grounder их четыре: web_search (ссылки и сниппеты), fetch (одна страница чистым текстом), deep_search (поиск, чтение верхних результатов и готовая подборка цитат) и research (многошаговый агентский прогон). Но важнее не список, а что именно приходит обратно.

Наивный вариант - вернуть модели весь HTML страницы - ломает маленькие модели. Целая страница это легко 20 000+ токенов вёрстки, меню и мусора, и она переполняет окно контекста в 8k. Поэтому grounder отдаёт не сырую страницу, а подборку с ограничением по токенам: ранжированные фрагменты по делу плюс ссылки на источники, обрезанные под ваш контекст параметром max_tokens. Для локальной модели это разница между «влезло и ответила» и «переполнилось и вернула пусто».

Ссылки на источники в подборке важны не для красоты: по ним модель может сослаться на конкретную страницу, а вы - проверить, откуда взят факт. Так ответ перестаёт быть «модель что-то вспомнила» и становится «модель прочитала вот эти страницы». Подробный разбор этого пути: веб-поиск для локальной LLM без VPN.

Как выглядит конфиг

Подключить MCP-сервер - это один блок в настройках клиента. Для grounder он такой:

// MCP-конфиг клиента: LM Studio, Claude Desktop, Cursor
{
  "mcpServers": {
    "grounder": {
      "command": "uvx",
      "args": ["grounder-mcp"],
      "env": { "GROUNDER_API_KEY": "gnd_live_ваш_ключ" }
    }
  }
}

Тонкий клиент ставится через uvx, ключ подставляется в env - и всё. После этого у модели появляются инструменты поиска и чтения. Полная пошаговая инструкция: как подключить нейросеть к интернету.

Безопасность: вы запускаете чужой код

Один сервер - все клиенты

Главная выгода стандарта: настроили сервер один раз - и он работает везде. Тот же блок конфига с grounder заводится и в LM Studio, и в Claude Desktop, и в Cursor, и в вашем собственном агенте. Переписывать интеграцию под каждую программу не нужно.

Одно исключение стоит держать в голове: Ollama сама MCP-хостом не выступает. Она гоняет модель, но инструменты не запускает, поэтому с ней берут MCP-совместимый клиент поверх. Разбор: как дать Ollama доступ в интернет.

grounder - наш продукт, и один из MCP-серверов, о которых тут речь, это он, так что интерес у нас есть. При этом устройство MCP и его ограничения одинаковы для любого сервера: связка клиент-сервер, вызов по решению модели, транспорт через локальный процесс или сеть - это часть стандарта, а не нашей реализации.

Частые вопросы