1С и AI от хайпа к практике. Создаем MCP-сервер для интеграции ваших баз с LLM

1С и AI от хайпа к практике. Создаем MCP-сервер для интеграции ваших баз с LLM

Эта статья имеет практический характер. Я расскажу, как с помощью MCP-серверов превратить чат с языковой моделью из малополезной игрушки в мощный инструмент – экзоскелет специалиста 1С.

Многие пробовали использовать чаты с языковыми моделями для решения рабочих задач. Сначала возникает вау-эффект: просишь модель написать код – она пишет, и он может даже работать. Но как только появляется более сложная задача, требующая специфических знаний о вашей конфигурации, магия исчезает. Модель начинает галлюцинировать, выдумывать несуществующие объекты и методы, и результат получается не таким, какой мы хотели.

Это проблема информационного разрыва между тем, что модель знает, и тем, что она должна знать, чтобы решить задачу. Я покажу, как ее можно решать с помощью open-source инструмента, который вы , надеюсь, установите и начнете осваивать уже сегодня. Прежде чем перейти к решению, разберем саму проблему и введем несколько базовых понятий.

Контекст как основа для качественного ответа модели

Есть известный принцип: качество решения, которое дает языковая модель, определяется качеством подготовленного для нее контекста. У модели есть рабочая память – контекстное окно. Чтобы модель дала хороший результат, нужно грамотно наполнить его релевантной для решаемой задачи информацией.

Эту информацию можно представить как айсберг: верхушка – это промпт, который мы вводим в модель, а подводная часть – контекст, который мы обычно не передаем, но без него задачу эффективно не решить.

На примере из 1С-разработки: если мы хотим, чтобы модель исправила ошибку в отчете, нужно передать не только описание отчета и текст сообщения об ошибке, но и исходные модули, тексты запросов, структуру таблиц конфигурации и данные, на которых ошибка проявляется. Все это должно быть передано в формате, удобном для обработки языковой моделью.

Это можно сравнить с написанием детального ТЗ для программиста-стажера, который только пришел в компанию и ничего не знает: его нужно вводить в курс дела, все показывать и объяснять, чтобы он смог выполнить задачу. Это большая работа, и неудивительно, что иногда проще сделать все руками, чем пытаться объяснить задачу модели. Именно эта проблема мешает активно внедрять языковые модели в рабочие процессы.

Часто проще сделать задачу вручную, чем пытаться подготовить для модели полноценный контекст. Это подводит нас к решению. Если подготовка контекста вручную – тупиковый путь для сложных задач, то что, если модель сможет самостоятельно собирать всю необходимую для решения информацию?

Появление MCP (Model Context Protocol)

Современные модели уже способны собирать нужную информацию самостоятельно. Но для того, чтобы все системы с искусственным интеллектом и языковые модели делали это по одним принципам, необходим единый стандарт.

Здесь появляется Model Context Protocol (MCP). Самая интересная его часть – возможность описывать взаимодействие языковой модели с внешними системами: файлами на компьютере, базами данных и другими источниками.

Если продолжить аналогию со стажером, нам не нужно каждый раз составлять ему детальное ТЗ. Мы один раз даем инструкции: код бери здесь, структуру таблиц смотри здесь, данные получай так. MCP позволяет задать такие же инструкции языковой модели и помогает ей следовать им.

Еще раз: ключевая идея в том, что модель самостоятельно собирает всю необходимую информацию. Таким образом, самая трудоемкая и рутинная часть – сбор контекста для модели – автоматизируется.

Что такое MCP, мы уже разобрали. Теперь посмотрим, как он работает.

Архитектура MCP: клиент и сервер

В схеме работы MCP есть два ключевых участника: MCP-клиент и MCP-сервер.

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

MCP-сервер – это сервис, имеющий доступ к источнику данных: файлам на компьютере, базе данных или, что особенно интересно для специалистов 1С, базе 1С. Основная задача сервера – принять запрос, обратиться к источнику данных, получить нужную информацию, оформить ее в удобном для языковой модели виде и передать модели. Таким образом, MCP-сервер – это мост или адаптер между языковой моделью и внешними системами.

Пошаговый пример работы MCP

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

Языковая модель сама по себе ничего полезного на такой запрос не ответит, у нее нет такой информации. Но она знает, что у нее есть доступный MCP-сервер, который умеет эту информацию выдавать. Зная это, она не генерирует бесполезный ответ пользователю, а формирует запрос на получение данных от MCP-сервера.

Клиент видит, что от языковой модели пришел не произвольный текст для пользователя, а запрос на вызов MCP-сервера, и передает этот запрос MCP-серверу.

Сервер получает данные из 1С, оформляет их в удобном для модели виде и возвращает клиенту. Клиент подмешивает эти данные в чат с моделью, снова вызывает языковую модель, и она формирует для пользователя полезный качественный ответ.

То есть можно это представить так: в чате, кроме вас и языковой модели, есть MCP-сервера. Языковая модель может писать сообщения вам, а может писать запросы на получение данных к MCP-серверам. А MCP-сервера подкидывают в чат запрошенные данные.

С теорией закончили, переходим к практике. Приведу несколько кейсов, которые считаю наиболее интересными и полезными для разных ролей в мире 1С.

Кейс для программистов: MCP по метаданным

Начнем с программистов. Для них уже разработано огромное количество систем с искусственным интеллектом. В том числе вендор предлагает 1С:Напарник (правда о нем говорить не будем, он пока не поддерживает MCP). Что это за системы?

• среды разработки с искусственным интеллектом (AI-first IDE) – например, Cursor и Windsurf,

• плагины для IDE – например, Cline и RooCode,

• инструменты командной строки (CLI-инструменты) – например, Claude Code и Gemini CLI.

Все эти инструменты подходят для 1С-разработки. Вы выгружаете конфигурацию в XML, открываете папку выгрузки в одной из таких систем и начинаете работать с кодом.

Эти системы уже изначально умеют работать с файловой системой: искать, читать и записывать файлы. Некоторые могут выполнять интернет-поиск. И все их можно расширять путем подключение MCP-серверов.

Какие MCP могут быть полезны для 1С-разработчика? Модели постоянно развиваются. Многие уже неплохо пишут код 1С, некоторые делают это хорошо, знают платформу, кое-что – о БСП. Но они ничего не знают о ваших конфигурациях, проектах и доработках. С помощью MCP можно добавить эти знания.

Наиболее полезным, с моей точки зрения, является MCP, который умеет выдавать метаданные вашей конфигурации в эти системы. Я использую его практически каждый день, потому что около 90% задач разработки так или иначе требуют информации о метаданных. С таким MCP модели становятся более точными и практичными, а круг задач, которые можно решать с их помощью, значительно расширяется.

Где взять такие MCP? Есть несколько проектов на GitHub и на маркетплейсе Infostart. Обычно они работают так: обрабатывают выгрузку конфигурации в XML и формируют внутреннюю базу данных, с которой можно работать через MCP.

Есть и мой проект, о котором расскажу ниже. Он подключается напрямую к вашей базе в виде расширения и выдает метаданные напрямую – без выгрузок. Обновили базу – и через MCP сразу доступны актуальные метаданные конфигурации и расширений.

Демонстрация работы MCP в реальной задаче

Посмотрим на примере, как выглядит работа программиста с таким MCP.

Предположим, у нас есть среда разработки Cursor и обработка, которая перестала работать после обновления основной конфигурации УТ 11. Вышло несколько релизов, метаданные сильно изменились.

Как бы мы действовали вручную? Открыли бы конфигуратор, начали бы разбирать код, анализировать запросы, смотреть, к каким метаданным идет обращение, какие реквизиты используются, насколько они актуальны, и вносили бы правки.

Все это мы можем попросить сделать Cursor, с кодключенным к нему MCP по метаданным.

Cursor читает файлы и по ходу работы обращается к MCP-серверу, получает метаданные, сверяет их с текущими и вносит изменения.

В результате вместо четырех часов сосредоточенной ручной работы вы тратите примерно час. Почему не пять минут? Потому что результат нужно проверить и, при необходимости, скорректировать. Ответственность за результат лежит не на языковой модели, а на нас – разработчиках.

Кейс для аналитиков: работа с метаданными и данными

Аналитик может использовать те же инструменты, что и программист. Среда разработки с языковыми моделями – это не только про код, а про любые тексты. Правда, придется работать с чистым текстом в формате Markdown. Я, когда выступаю в роли аналитика, работаю именно так.

Можно использовать и привычные чаты – некоторые из них поддерживают подключение MCP. Например, Claude Desktop и LibreChat.

Какие MCP полезны аналитику? Прежде всего – тот же MCP по метаданным. Когда мы пишем ТЗ, модель ограничена рамками нашей конфигурации и оперирует реальными именами объектов, реквизитов, типов и т.д. В результате мы получаем гораздо более точный и полезный результат.

Или другой пример – проектирование нового объекта. Современные языковые модели достаточно умные, чтобы самостоятельно проанализировать требования пользователя, структуру конфигурации и учесть дополнительные требования. В итоге мы получаем результат, с которым можно реально работать.

Кроме того, аналитик часто работает с данными – анализирует ошибки, проверяет правильность учета, проводит сверки. Здесь может помочь другой инструмент – MCP по запросам.

Система с таким MCP работает в два этапа. На первом этапе модель формирует текст запроса на основе задания аналитика, используя MCP по метаданным и структуру конфигурации. На втором этапе возможны два варианта:

1. Модель проверяет запрос в базе, получает от платформы обратную связь, корректирует ошибки и выдает готовый корректный запрос с которым можно дальше работать в консоли запросов.

2. Запрос выполняется напрямую через MCP, получаются данные, и модель сразу выдает конечный результат анализа.

Пример анализа данных через MCP

Как это может выглядеть? Аналитик просит модель посчитать статистику по документу.

Модель получает через MCP структуру документа и создает запрос. Вторым вызовом MCP она выполняет этот запрос в базе, получает данные и выдает конечный результат.

Получается универсальный отчет, не требующий знаний программирования или языка запросов. Пишешь запрос на естественном языке – получаешь нужные данные.

Но есть нюансы. Во-первых, выборка должна быть сравнительно небольшой. Современные языковые модели имеют ограниченное контекстное окно и не могут обрабатывать большие объемы данных.

Во-вторых, вопрос безопасности: такие операции можно проводить с облачными моделями только в тестовых базах или обезличенных копиях. Если анализ выполняется на рабочей базе, это должен быть закрытый контур, а обработка данных – локальной моделью, чтобы информация не уходила за пределы организации.

Кейс для конечных пользователей: история документа

С пользователями можно придумать множество вариантов работы с языковыми моделями и MCP, но вопрос в том, насколько они приживутся. Опыт показывает, что не любую задачу удобно решать в режиме чата. Однако один кейс у нас прижился, и мы используем его время от времени.

В конфигурациях 1С есть стандартная система версионирования и отчет по версиям. Мы сделали небольшой MCP, который отвечает на конкретные вопросы пользователя по истории документа.

Здесь вопрос безопасности особенно важен: такой MCP полезен только в рабочей базе, поэтому мы запускаем его в LM Studio. Используется модель gemma-3 с 12 миллиардами параметров. Это сравнительно небольшая модель, я запускаю ее даже на домашней видеокарте. При этом она достаточно умная, может работать с MCP и решать несложные задачи.

Как это работает: инструменты (tools) и их описание

Мы видели выше, что модели сами запрашивают данные и метаданные. Возникает вопрос – как у них это получается? Мы уже привыкли, что обычно, если модели не хватает данных, она начинает их выдумывать.

Секрет в том, что современные языковые модели в процессе обучения учатся не просто генерировать текст, но и распознавать ситуации, когда нужно выполнить действие – например, получить данные. В таких случаях они генерируют запрос специального формата на вызов так называемых инструментов (tools).

Инструмент (tools) – это по сути функция с параметрами, запрос на вызов которой может сгенерировать языковая модель. MCP-сервер обычно предоставляет сразу несколько таких инструментов – получается API, через которое модель взаимодействует с системой, представляемой MCP-сервером.

Описание инструмента в MCP

Инструмент: list_metadata_objects

Назначение: Получение списка объектов метаданных конфигурации с возможностью фильтрации по типу и имени

Параметры:

Описание инструмента содержит:

• имя, по которому модель обращается к инструменту;

• назначение, по которому она понимает, когда его можно вызывать;

• параметры с информацией о том, какие данные нужно в них передавать, и ограничениями (тип, список допустимых значений).

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

Реализация MCP-сервера в 1С: проект 1C_MCP

Как это сделать в 1С? Здесь мы подходим к моему open-source проекту – 1С_MCP: github.com/vladimir-kharin/1c_mcp. Он представляет собой расширение конфигурации, которое берет на себя всю техническую рутину по реализации протокола MCP.

Не нужно разбираться в спецификациях протокола. Ваша задача – реализовать бизнес-логику: продумать структуру инструментов, их параметры, логику работы и возвращаемые данные.

// Описание инструментов

Процедура ДобавитьИнструменты(Инструменты) Экспорт

// Регистрируем инструмент

КонецПроцедуры


// Действие инструментов

Функция ВыполнитьИнструмент(Имя, Параметры) Экспорт

// Логика инструмента

КонецФункции

Чтобы добавить новый инструмент, делаем два шага:

1. Добавляем в расширение обработку и включаем ее в подсистему mcp_КонтейнерыИнструментов.

2. В модуле менеджера обработки реализуем два экспортных метода:

   • ДобавитьИнструменты - выдает список описаний инструментов, о которых я говорил ранее,

   • ВыполнитьИнструмент - реализует логику инструмента и формирует возвращаемое значение.

В проекте 1С_MCP уже «из коробки» есть готовые инструменты: получение списка метаданных и получение структуры конкретного объекта метаданных. Их можно использовать сразу после установки – просто скачать проект и подключить.

Я включил эти инструменты, потому что при создании любых универсальных доработок чаще всего нужна информация о метаданных. И она уже встроена, а вы можете дополнять ее своими инструментами и расширять функциональность.

Технические нюансы подключения: транспорты и авторизация

Хорошо, мы сделали инструмент в 1С. Как модель сможет его вызывать? Протокол MCP предлагает два способа коммуникации между клиентом и сервером (транспорта): stdio и HTTP.

Stdio для 1С не подходит: платформа не позволяет нам создавать консольные приложения. А вот HTTP транспорт мы сможем реализовать через HTTP-сервис.

В расширении 1С_MCP уже реализован такой HTTP-сервис: публикуете его на веб-сервере, подключаете к клиенту по адресу <адрес вашей базы>/hs/mcp/ и начинаете работать со своим MCP-сервером.

Но есть два нюанса:

1. В протоколе MCP предусмотрены долгоживущие соединения с частичной передачей возвращаемых данных (стриминг). Платформа 1С пока не позволяет реализовать такие соединения. Это не критично, большинство клиентов MCP могут работать без стриминга. Более серьезная проблема: некоторые клиенты не поддерживают HTTP и могут подключать MCP-сервера только по stdio.

2. HTTP-сервисы в 1С предполагают basic-авторизацию, а протокол MCP – OAuth 2. Получается несостыковка, и если мы хотим напрямую подключать к клиенту MCP-сервер в 1С, придется публиковать HTTP-сервисы без авторизации.

Для решения этих инфраструктурных проблем в проекте 1С_MCP есть дополнительный компонент – proxy-прокладка. Это небольшое Python-приложение. В нем мы указываем адрес базы, из которой опубликован HTTP-сервис, при необходимости – логин и пароль пользователя. Дальше подключаем к MCP-клиенту этот прокси. Его можно подключить и через stdio (установив на той же машине, где MCP-клиент), и через HTTP с поддержкой стриминга (разворачивая, например, на том же сервере, где крутится 1С).

Есть также режим «проброса» авторизации: вы авторизуетесь на MCP-сервере, открывается окно браузера, вводите логин и пароль 1С, и все запросы в 1С идут от имени пользователя, под которым вы авторизовались.

Вопросы безопасности при работе с данными

Пару слов о безопасности данных. Если мы работаем с облачными моделями, нужно помнить, что данные отправляются далеко и скорее всего за границу. Для кода 1С это не критично – в 95–99% случаев он типовой, ничего секретного в нем нет, пусть уходит, это даже полезно: модели на нем обучаются и со временем лучше пишут код 1С.

Но если речь о данных, особенно о персональных, это уже риск. Решить проблему можно, все необходимые инструменты есть:

• LibreChat – корпоративный чат с LLM и поддержкой MCP (можно развернуть во внутренней сети),

• LM Studio или Ollama – приложения для запуска моделей на своем железе. При выборе локальных моделей обращайте внимание, чтобы они поддерживали tool calling – механизм вызова инструментов (это необходимо для стабильной работы MCP).

С чего начать?

1. Скачайте проект с GitHub.

2. Установите расширение.

3. Опубликуйте HTTP-сервис.

4. (Опционально) создайте первый инструмент.

5. Подключите проект к Cursor.

Попробуйте решить несколько простых задач в Cursor, опираясь на иснтрументы работы с метаданными, а когда разберетесь как это работает, освоитесь – начинайте создавать свои инструменты.

Заключение

Внедрение инструментов с ИИ в нашу работу и в бизнес наших клиентов – это не далекая перспектива, а реальность, доступная уже сейчас. Я считаю, что этим нужно заниматься уже сегодня. Весь необходимый инструментарий у нас под рукой. Ничего сверхсложного в нем нет: не нужно быть ML-инженером, чтобы все освоить.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.