http1c 是一个用于构建 1C：Enterprise 模型上下文协议（MCP）服务器的框架。它提供了一个本地组件（DLL），负责管理 MCP 传输层，以及一个参考 1C 数据处理器，演示如何实现工具、资源和提示符。

将其作为模板，将任何1C业务逻辑——目录、文档、报告、计算——暴露给像VS Code Copilot、Claude Desktop及其他兼容MCP的客户端在内的AI应用。

核心概念

项目有意分为两层，各自承担不同的职责。

本地组件职责

DLL是MCP引擎。它处理协议和传输细节，这些细节不应在1C业务代码中重现：

• HTTP/SSE 传输
• JSON-RPC 请求/响应生命周期
• MCP会话管理
• 认证、起源验证和速率限制
• 分页、通知和进度流
• 将1C响应转换为有效的MCP回复

1C 职责

1C端拥有业务逻辑。1C开发者应在工具、资源和提示符层面工作，而非MCP内部层面：

• 用BSL描述工具/资源/提示词

http1c — MCP Server Framework for 1C:Enterprise

http1c is a framework for building Model Context Protocol (MCP) servers from 1C:Enterprise. It provides a native component (DLL) that handles the MCP transport layer and a reference 1C data processor that demonstrates how to implement tools, resources, and prompts.

Use it as a template to expose any 1C business logic — catalogs, documents, reports, calculations — to AI applications like VS Code Copilot, Claude Desktop, and other MCP-compatible clients.

Core Concept

The project is intentionally split into two layers with different responsibilities.

Native component responsibilities

The DLL is the MCP engine. It handles protocol and transport details that should not be reimplemented in 1C business code:

• HTTP/SSE transport
• JSON-RPC request/response lifecycle
• MCP session management
• authentication, origin validation, and rate limiting
• pagination, notifications, and progress streaming
• converting 1C responses into valid MCP replies

1C responsibilities

The 1C side owns business logic. A 1C developer should work at the level of tools, resources, and prompts, not at the level of MCP internals:

• describe a tool/resource/prompt in BSL
• register it in the component
• handle the incoming call in 1C
• run any required client-side or server-side 1C logic
• return the result or send progress updates

Why the project is designed this way

The goal is to let a 1C developer publish almost any 1C functionality through MCP without having to understand HTTP, JSON-RPC, SSE, session handling, or MCP message formatting.

In other words:

• the component knows how to be an MCP server
• 1C knows what the tool actually does

This keeps the integration point simple. To add new functionality, a 1C developer does not need to change the native transport layer. They only add or update 1C definitions and handlers.

Mental model for a 1C developer

From the 1C side, the workflow is intentionally simple:

1. Define the MCP object in BSL.
2. Register it in the component.
3. Receive the request through ExternalEvent.
4. Execute arbitrary 1C logic.
5. Return the final result, and optionally send progress while the operation is running.

This means the project is not a fixed set of built-in utilities. It is an MCP transport and protocol layer for 1C, with the actual application behavior defined in 1C code.

Key Features

• Full MCP protocol support — tools, resources, prompts with listChanged notifications
• Streamable HTTP transport — POST /mcp for requests, GET /mcp for SSE notification stream
• Session management — Mcp-Session-Id header, UUID v4 sessions per spec
• Security — Origin validation (DNS rebinding protection), Bearer token auth, rate limiting
• Progress streaming — SSE-based progress notifications for long-running operations