Справочник

MCP-сервер

Model Context Protocol (MCP) — открытый стандарт для подключения инструментов к ИИ-агентам. Через MCP-сервер srezai.ru агент получает поиск и исследования как встроенные инструменты, без ручной интеграции REST.

Что такое MCP

MCP позволяет ассистентам (Claude, IDE-агентам и совместимым клиентам) вызывать внешние инструменты по единому протоколу. Вы подключаете сервер один раз — агент сам решает, когда искать в вебе.

Эндпоинт#

Сервер работает по транспорту Streamable HTTP на едином адресе. Авторизация — тем же ключом srz_live_…, что и REST:

POSThttps://srezai.ru/api/mcp

Подключение#

Добавьте srezai.ru в конфигурацию MCP-клиента, указав ваш API-ключ в заголовке Authorization:

json
{
  "mcpServers": {
    "srezai": {
      "url": "https://srezai.ru/api/mcp",
      "headers": {
        "Authorization": "Bearer srz_live_ВАШ_КЛЮЧ"
      }
    }
  }
}

Формат ключа и правила безопасности — в разделе Аутентификация.

Если клиент не умеет HTTP#

Часть клиентов подключает MCP-серверы только запуском процесса. Для них есть пакет srezai-mcp: он поднимается локально и пересылает вызовы на тот же эндпоинт. Ставить отдельно не нужно, npx скачает его сам:

json
{
  "mcpServers": {
    "srezai": {
      "command": "npx",
      "args": ["-y", "srezai-mcp"],
      "env": { "SREZAI_API_KEY": "srz_live_ВАШ_КЛЮЧ" }
    }
  }
}

Инструменты и их параметры пакет запрашивает у сервера, а не хранит в себе, поэтому новые появляются без обновления версии. Нужен Node 18+. Исходники — srezai-mcp на GitHub, зеркало — на GitVerse.

Открытый код#

Мост открыт под лицензией MIT — его можно прочитать целиком перед тем, как отдавать ему ключ. Кода немного: приём строки JSON-RPC из stdin, пересылка на /api/mcp с вашим ключом и вывод ответа в stdout. Список инструментов и цены живут на сервере, поэтому в пакете их нет.

  • github.com/srezai-team/srezai-mcp — основной репозиторий, там же релизы и теги версий.
  • gitverse.ru/a1_ai_a4b/srezai-mcp — зеркало для тех, кому GitHub недоступен или неудобен. Обновляется вслед за основным; PR принимаются только на GitHub, иначе истории разъедутся.

Доступные инструменты#

  • web_search — веб-поиск с категориями и фильтрами. Параметры: query (обязателен), category, timeRange, language, num, excerpts (подтянуть реальный текст топ-страниц), includeDomains / excludeDomains (искать только на указанных сайтах или исключить их, до 10 доменов). Та же логика, что и у /api/v1/search.
  • image_search — поиск изображений. Параметры: query (обязателен), timeRange, safe. См. /api/v1/media.
  • read_url — текст страницы в чистом markdown. Параметры: url (обязателен), maxChars (200–50000), offset (продолжить чтение длинной страницы), engine (auto по умолчанию), fresh (минуя кеш). Не влезло в maxChars — в конце ответа готовое значение offset для следующего вызова, так что документ любого объёма читается по частям под ваш контекст. Скриншот не делает — дешевле и быстрее fetch_page. См. /api/v1/read.
  • read_urls — то же чтение для пачки ссылок. Параметры: urls (обязателен, 1–5 адресов), maxChars, engine, fresh. Страницы читаются параллельно, упавшая ссылка не отменяет остальные, каждая тарифицируется как отдельное чтение. offset здесь нет намеренно: он был бы общим на весь батч — продолжение адресуется на read_url. См. Несколько страниц за раз.
  • fetch_page — скриншот и структура страницы. Параметры: url (обязателен), maxChars (сколько символов текста вернуть, 200–50000). Открывает страницу в браузере и возвращает скриншот картинкой (её видит vision-модель), ссылку на полноразмерный PNG и текст в markdown. См. /api/v1/fetch.
  • extract — структурированные данные со страницы по вашей JSON Schema. Параметры: url или urls (1–5 ссылок, одна схема на все), schema (обязателен), instruction, engine. Возвращает только описанные схемой поля; чего на странице нет — null. См. /api/v1/extract.
  • verify_claim — проверка утверждения по источникам. Параметры: claim (обязателен, до 500 символов), maxSources (2–5), timeRange, language, query. Сам ищет источники, читает их и возвращает вердикт с дословными цитатами; цитата, не найденная в тексте страницы, отбрасывается вместе с доводом. Вердикты mixed и unverified — нормальный результат, а не ошибка. См. /api/v1/verify.
  • answer_search — полный RAG-цикл с семантическим ранжированием. Параметры: query (обязателен), depth (fast / balanced / deep), language. Поиск → BGE-reranker отбирает топ по релевантности → чтение страниц → синтез ответа. Возвращает готовый ответ с указанием relevance каждого источника (0–1). См. Answer Search.
  • deep_research — агентное исследование. Параметр: query (обязателен). Синхронный вызов на 10 сек – 2 мин. См. DeepResearch.
  • get_usage — остаток на счёте, расход суточной квоты, burst-лимит и цены инструментов в кредитах. Без параметров. Вызов бесплатный и квоту не расходует, поэтому агент может спросить остаток даже упёршись в лимит. REST-аналога нет: в REST то же самое приходит в заголовках X-RateLimit-*.

Проверка: список инструментов#

Убедиться, что сервер отвечает и ключ принят, можно вызовом tools/list по JSON-RPC 2.0. Заголовок Accept обязателен — сервер отвечает потоком text/event-stream:

bash
curl -X POST https://srezai.ru/api/mcp \
  -H "Authorization: Bearer srz_live_ВАШ_КЛЮЧ" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Если у модели окно 32–64k

Сервер сообщает агенту, что сырые страницы в маленький контекст набивать не надо, и что для этого есть: read_url с offset отдаёт документ порциями под размер окна, extract возвращает только запрошенные поля вместо всего текста, verify_claim переваривает 4–5 источников на нашей стороне. Во всех трёх случаях черновая работа идёт вне контекста модели — поэтому набор одинаково работает и на 32k, и на 200k.

Предпочитаете REST?

MCP — это удобная обёртка. Если вы строите собственный пайплайн, работайте напрямую с REST API — контракты те же самые.