MCP для 1С: как подключить Claude или GPT к базе 1С в 2026

Что такое MCP и зачем он для 1С

MCP (Model Context Protocol) — это открытый протокол от Anthropic для подключения языковых моделей к внешним данным и инструментам. Идея простая: вместо того чтобы под каждую модель и каждую систему писать отдельный коннектор, вводится единый стандартизированный слой. Модель говорит с MCP-сервером по общим правилам, а уже сервер знает, как достучаться до конкретной системы — базы данных, API, файлов или учётной системы.

Для мира 1С это интересно по одной причине. Данные о деньгах, товарах, контрагентах и документах у большинства компаний лежат именно в 1С. Если языковая модель — Claude, GPT или другая — сможет читать эти данные и вызывать операции в базе, открывается целый класс сценариев: спросить у ассистента про остатки на складе, попросить свести долги по контрагенту, сформировать черновик отчёта. Раньше каждый такой мост приходилось строить руками. MCP предлагает общий язык для этого моста.

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

Как это устроено: LLM ↔ MCP-сервер ↔ 1С

Типовая схема для бизнес-сценария состоит из трёх звеньев: языковая модель (Claude, GPT), MCP-сервер и сама 1С. Модель формулирует запрос, MCP-сервер переводит его в конкретные вызовы к 1С, получает ответ и возвращает его модели в понятном виде.

Соединение с 1С со стороны MCP-сервера обычно идёт через два механизма платформы: OData или HTTP-сервисы. OData — это опубликованный REST-подобный интерфейс к справочникам и документам базы, ближайший слой к бизнес-данным. HTTP-сервисы — способ выставить наружу собственную серверную логику, написанную на встроенном языке. Какой механизм выбрать, зависит от того, что именно вы хотите отдавать модели: сырые справочники и документы или заранее подготовленные операции.

Отдельная тема — транспорты самого MCP, то есть то, как модель общается с сервером. В спецификации их несколько: stdio, HTTP, SSE и Streamable HTTP. На практике open-source проекты чаще используют stdio — это удобно для локального подключения к клиентам вроде Cursor или Claude, где сервер запускается как отдельный процесс и обменивается сообщениями через стандартные потоки ввода-вывода.

Есть и неочевидный технический нюанс на стыке протоколов. HTTP-запросы к 1С традиционно используют basic-аутентификацию (логин и пароль в заголовке), тогда как MCP ориентирован на OAuth 2. Эти модели не совпадают напрямую, поэтому в некоторых архитектурах между HTTP-слоем 1С и MCP-клиентом ставят прокси-прослойку, которая разбирается с аутентификацией и форматами. Ниже, на разборе конкретного проекта, мы увидим, как это выглядит в реальности.

Что уже есть: каталог и живые серверы

Точка входа в тему — курируемый каталог MCP-серверов для 1С, который живёт на GitHub по адресу github.com/Untru/1c-mcp. Это удобная отправная точка: там собраны проекты, которые действительно работают, а не только упоминаются в презентациях.

Разберём основные живые проекты по порядку.

• mcp-1c — сервер, написанный на Go. Подключается к 1С через HTTP-сервисы, умеет читать метаданные конфигурации и выполнять запросы. Это скорее инструмент для чтения и исследования структуры базы.
• 1c-rest-mcp — подключается к опубликованным REST/OData API 1С и работает с операциями над справочниками и документами. Именно этот слой ближе всего к бизнес-данным: справочники контрагентов, номенклатура, документы. Если ваша цель — дать модели доступ к учётным сущностям, смотреть стоит в первую очередь сюда.
• 1c_mcp — open-source проект Владимира Харина (github.com/vladimir-kharin/1c_mcp). Работает по HTTP, поддерживает клиенты Cursor, Windsurf и Claude. Его разбираем детальнее в следующем разделе.
• ARQA MCP Server — коммерческое решение. В отличие от предыдущих, заявляет не только чтение, но и создание документов и формирование отчётов через ИИ.

Разброс проектов показывает две вещи. Во-первых, сообщество вокруг темы есть, и оно активно. Во-вторых, проекты различаются по зрелости и назначению: одни читают метаданные, другие работают с бизнес-данными, третьи — коммерческие и берут на себя запись. Выбор зависит от задачи, а не от самого популярного имени.

Разбор 1c_mcp и 1c-rest-mcp

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

1c_mcp: чтение метаданных и мост аутентификации

Проект Владимира Харина — открытый, работает по HTTP. Из инструментов он предоставляет модели, в частности, list_metadata_objects (перечислить объекты метаданных) и get_metadata_structure (получить структуру конкретного объекта). То есть базовый сценарий — дать модели возможность разобраться, как устроена конфигурация: какие есть справочники, документы, регистры и как они выглядят.

Здесь наглядно проявляется тот самый разрыв протоколов. HTTP-запросы к 1С используют basic-аутентификацию, а MCP рассчитан на OAuth 2. Чтобы состыковать одно с другим, в архитектуре появляется Python-прокси, который стоит между HTTP-слоем 1С и stdio-клиентом MCP. Прокси берёт на себя перевод между двумя мирами. Это не изъян проекта, а типовое следствие того, что два стандарта проектировались независимо. Работает связка с клиентами Cursor, Windsurf и Claude.

1c-rest-mcp: ближе к бизнес-данным

Если 1c_mcp хорош для знакомства со структурой, то 1c-rest-mcp нацелен на сами данные. Он подключается к опубликованным REST/OData API 1С и работает с операциями над справочниками и документами. Практически это означает доступ к тому, что интересно бизнесу: контрагенты, номенклатура, конкретные документы. Именно поэтому в задачах вида покажи данные по клиенту этот слой обычно оказывается точкой приложения усилий.

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

Что реально можно сделать сейчас (и чего пока нет)

Разделим желаемое и действительное честно, без маркетинговых обобщений.

Что реально доступно уже сегодня из строительных блоков:

• Дать модели прочитать метаданные конфигурации — список объектов и их структуру (инструменты вроде list_metadata_objects и get_metadata_structure).
• Подключиться к OData/REST 1С и читать справочники и документы через слой вроде 1c-rest-mcp.
• Собрать связку LLM ↔ MCP-сервер ↔ 1С через OData или HTTP-сервис и работать с ней из Cursor, Windsurf или Claude.
• В коммерческих решениях (ARQA) — создавать документы и формировать отчёты через ИИ.

Чего пока честно нет в открытом доступе: зрелых промышленных кейсов вида LLM-агент сам читает остатки и долги из 1С:Бухгалтерии через MCP и на этом строится рабочий процесс. Есть строительные блоки и есть статьи-концепты — например, разборы на Инфостарт — но готовых, обкатанных на потоке решений почти нет. Ниша именно формируется.

Практический вывод для техлида: относитесь к MCP-для-1С как к перспективному пилоту, а не как к готовому продукту с гарантией. Начинайте с узкого, хорошо очерченного сценария на чтение, где ошибка модели не приводит к порче данных. Разбор конкретных сценариев ассистента для учётных задач мы вынесли в отдельный материал об ИИ-ассистенте для бухгалтера в 1С.

Безопасность и с чего начать

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

Несколько разумных ориентиров на старте:

1. Начните с чтения. Первый пилот — только доступ на чтение метаданных или ограниченного набора справочников. Никакой записи, пока связка не отлажена и не понятна.
2. Ограничьте область данных. Публикуйте через OData или HTTP-сервис не всю базу, а конкретный минимальный набор объектов, нужный для сценария.
3. Отдельная учётная запись. Заведите под интеграцию отдельного пользователя 1С с минимальными правами, а не подключайтесь под администратором.
4. Осознайте слой аутентификации. Помните про разрыв между basic-аутентификацией HTTP-запросов 1С и OAuth 2 в MCP. Прокси-прослойка, которая это стыкует, — часть периметра безопасности, и относиться к ней нужно соответственно.
5. Выберите транспорт под задачу. Для локального пилота с Cursor или Claude обычно достаточно stdio; сетевые транспорты (HTTP, SSE, Streamable HTTP) добавляют гибкости, но и поверхность атаки.

С чего начать практически: откройте каталог github.com/Untru/1c-mcp, выберите проект под свою цель — для знакомства со структурой подойдёт 1c_mcp, для работы с бизнес-данными смотрите в сторону 1c-rest-mcp — и разверните его на тестовой базе, а не на боевой. Пройдите путь от чтения метаданных к чтению справочников, зафиксируйте, где связка ведёт себя предсказуемо, и только потом обсуждайте более смелые сценарии с записью.