MCP для сайта: как ИИ помогает находить ошибки, подбирать товары и работать с бизнес-данными

Зачем сайту MCP

Поисковый робот обычно обходит страницы и строит собственный индекс. AI-клиент, подключённый по MCP, работает иначе: сначала запрашивает список возможностей, затем выбирает нужный инструмент или ресурс. Например, вместо попытки извлечь услуги из меню и HTML он вызывает list_services, а для конкретной страницы — get_service.

Практические задачи: кому и чем помогает MCP

MCP — не самостоятельный ИИ и не замена API. Это стандартный способ дать AI-клиенту разрешённые инструменты и данные. Польза появляется там, где сервер предоставляет качественные данные, а клиент умеет последовательно вызвать несколько узких операций.

Архитектура без прямого доступа к базе

AI-клиент видит только схемы разрешённых инструментов и их ответы. Он не получает логин к базе, произвольный SQL или неограниченный доступ к внутренним сервисам. Публичный MCP для посетителей и внутренний MCP сотрудников должны быть разными контурами доступа.

Два реальных сценария ifreework.com

1. Найти материалы по теме

Вопрос: «Какие материалы есть про локальные LLM и RAG?» AI-клиент вызывает search_content с языком и разделами, получает заголовки, выдержки и канонические URL, а затем при необходимости читает выбранную статью через get_blog_post. В отличие от обычного поиска он работает с определёнными разделами и может продолжить диалог по полученным объектам.

2. Подготовить обращение владельцу

Вопрос: «Отправь запрос на разработку MCP-сервера». Сначала get_contact возвращает доступные способы связи, затем AI показывает пользователю точный текст и reply-to. Только после явного подтверждения вызывается send_message. Итог — валидированное обращение через тот же серверный механизм, что использует форма сайта; обычный поиск выполнить такое действие не может.

Подбор товаров, статусы заказов и бизнес-аналитика выше — потенциальные сценарии для сайтов, где реализованы соответствующие защищённые инструменты. На публичном MCP ifreework.com этих функций нет.

Из каких слоёв состоит правильная реализация

1. Источник опубликованных данных

   Отдельный read-only слой читает только публичные материалы CMS: страницы, услуги, портфолио и статьи. Черновики, служебные поля, пароли, сессии и административные данные не должны попадать в MCP даже случайно.

2. MCP endpoint

   Для удалённого сайта подходит Streamable HTTP, например https://example.com/mcp. Endpoint принимает JSON-RPC, обрабатывает initialize, tools/list, tools/call, resources/list и resources/read.

3. Инструменты с узкими контрактами

   У каждого инструмента есть понятное имя, описание и JSON Schema. Лучше несколько предметных операций — list_blog_posts, get_blog_post, search_content — чем универсальный SQL-запрос или произвольный URL.

4. Ресурсы

   Опубликованные страницы можно представить как MCP resources с URI, MIME-типом и текстовым содержимым. Инструменты удобны для запросов с параметрами, ресурсы — для чтения конкретного известного документа.

5. Discovery и описание подключения

   Server card описывает имя, версию и удалённый endpoint. AI Catalog или ARD связывает его с сайтом, а HTTP-заголовок Link указывает на каталог. Это помогает обнаружению, но не заставляет все AI-клиенты подключаться автоматически.

6. Публичный Registry

   Для официального MCP Registry готовится server.json, владение доменом подтверждается через DNS или файл /.well-known/mcp-registry-auth, после чего метаданные публикуются через mcp-publisher.

Как проектировать инструменты

Название инструмента должно объяснять результат без чтения реализации. Схема входа обязана быть строгой: тип объекта, допустимые поля, длины строк, диапазоны чисел и additionalProperties: false. Пустой properties в JSON должен быть объектом {}, а не массивом []: строгий SDK отклонит весь ответ tools/list, если хотя бы одна схема некорректна.

Ответу полезно включать:

• Канонический URLЧтобы AI мог сослаться на исходную страницу.
• ЯзыкЧтобы русская и английская версии не смешивались.
• Стабильный идентификаторДля повторного чтения выбранного материала.
• Границы выборкиПагинацию, максимальный limit и разрешённые разделы.
• Явные аннотацииreadOnlyHint, идемпотентность и наличие внешнего эффекта.
• Ошибки без внутренних деталейКлиенту нужен понятный код, но не SQL, stack trace или секрет конфигурации.

Read-only по умолчанию, подтверждение для действий

Для контентного сайта безопасная отправная точка — только чтение. Нельзя публиковать универсальное редактирование CMS, выполнение команд, произвольные запросы к базе или доступ к неопубликованным документам.

Если MCP всё же выполняет действие, оно должно быть отделено от чтения. На ifreework.com таким исключением является send_message: инструмент отправляет сообщение владельцу сайта, требует точный текст, обратный e-mail и confirmed_by_user=true. В описании сервера он явно обозначен как side-effecting, а не маскируется общей формулировкой «read-only».

Одного флага подтверждения недостаточно для защиты публичного endpoint. Нужны также:

• минимальные привилегии и read-only везде, где запись не нужна;
• авторизация для непубличных данных и разграничение ролей;
• подтверждение каждой операции, изменяющей данные;
• rate limit по клиенту и операции;
• ограничение размера JSON и длины каждого поля;
• валидация e-mail, URL и перечислений;
• идемпотентный request_id для безопасного повтора;
• защита от дублей и журналирование результата;
• таймауты и безопасные сообщения об ошибках;
• отсутствие секретов в результатах, логах и описаниях инструментов.

Что MCP не решает

MCP не гарантирует, что ChatGPT, Claude, поисковая система или любой другой клиент самостоятельно найдёт сервер и начнёт им пользоваться. Пользователь или владелец платформы по-прежнему должен добавить адрес подключения либо выбрать сервер из каталога.

Он также не заменяет качество самого сайта. HTML остаётся источником для людей и поисковых роботов, sitemap помогает обходу, Schema.org описывает сущности, llms.txt даёт компактную навигацию, а MCP предоставляет исполняемый контракт. Эти уровни работают вместе.

Как это организовано на ifreework.com

Публичный endpoint находится по адресу ifreework.com/mcp. Контентные инструменты читают опубликованные страницы на русском и английском, возвращают Markdown и канонические URL. Отдельные инструменты перечисляют услуги, проекты и статьи, читают выбранный материал, выполняют поиск и возвращают контакты.

Discovery опубликован через AI Catalog, ARD и server card. Человеческая инструкция доступна на странице MCP-сервер iFreeWork, а сервер com.ifreework/content зарегистрирован в официальном MCP Registry.

Через MCP реализована и отправка формы связи. Инструмент send_message использует тот же серверный механизм доставки, что и форма на сайте: принимает имя, обратный e-mail и текст обращения, проверяет данные, ограничивает повторы и передаёт сообщение владельцу. AI-клиент может вызвать его только после того, как пользователь увидел и подтвердил точный текст и адрес для ответа.

Главный принцип реализации прост: AI получает не «доступ к сайту вообще», а небольшой набор проверяемых контрактов поверх публичного контента. Именно эта граница делает MCP полезным в production, а не только эффектной демонстрацией.