Core-MCP-Middleware

A JSON-RPC middleware specification between an LLM agent and a 1C HTTP service: the protocol, authentication and a fix for UUID byte order

  • 0 ★ on the repository
  • Last commit
  • MIT
MCP server

Extended access

Why this level

  • The spec describes createDocument, updateDocument, deleteDocument tools that, once implemented, would change 1C data
  • There is no implementation, so the real risk depends on how a developer builds out the spec
All reasons and checks
Russian stack

kazancevaaroslava0-oss/core-mcp-middleware

Install

Manual install

Text for your agent

Read architecture.md and json_rpc_spec.md from the kazancevaaroslava0-oss/core-mcp-middleware repo as reference material for the protocol and the convert_uuid_to_1c_format function; the server implementation has to be written yourself.

Access and checks

How we review

Extended accessThe tool runs code or makes network calls and only reads external data.

  • The spec describes createDocument, updateDocument, deleteDocument tools that, once implemented, would change 1C data
  • There is no implementation, so the real risk depends on how a developer builds out the spec

This is third-party code. Review the repository files before installing.

What it does

The repository is a design document, not working code: it describes the architecture of a Python and FastAPI middleware that would accept JSON-RPC 2.0 calls from an LLM agent, check JWT authentication and forward requests to a 1C HTTP service. It separately works through a specific integration problem: 1C stores UUIDs in Little-Endian byte order while Python and most LLM tooling use Big-Endian, and gives the conversion function's code. The json_rpc_spec.md file specifies three methods: Auth to get a token, GetMetadata to read an object's metadata, and ExecuteTool to call tools like createDocument, getDocument, updateDocument, deleteDocument and getCatalog, with request, response and error code examples.

Who it is for. For 1C developers designing their own JSON-RPC bridge between an LLM agent and a 1C HTTP service, who want a ready fix for the UUID byte-order problem and a protocol example.

Good fit when

  • You need a JSON-RPC protocol example for agent-to-1C integration with Auth, GetMetadata and ExecuteTool methods
  • You need to solve the byte-order problem when passing UUIDs between Python and 1C
  • You want an architecture plan before writing your own code

Not a fit when

  • You need a ready-to-run server: the repo has no implementation, only design documents
  • You need the 1C HTTP service with Auth, GetMetadata, ExecuteTool methods: only the middleware side is described, the 1C part is not included

Example request

How do I correctly convert a UUID from Python to the 1C format for a JSON-RPC request?

MCP

Transport
http
Authentication
API key

Limitations

The repo has not one line of working code: only a README, an architecture document with a single UUID-conversion function example, and a text specification of JSON-RPC methods. There is no FastAPI server, no client, no 1C HTTP service, no tests, no releases. This is a design draft, not an installable tool.

How to disable. Nothing to disable: the repo contains no working service.

FAQ

Can I run this middleware?

No, the repo contains only design documents: a README, an architecture diagram and a JSON-RPC spec, with no working code.

What exactly is the UUID problem?

1C stores UUIDs in Little-Endian byte order while Python and most LLM tooling use Big-Endian; the document gives a function that converts the first three UUID groups.

Discussion

No questions or reviews yet.

Russian stack

A 1C external data processor with MCP and REST API: queries, metadata, event log and code execution without changing the configuration

MCP serverBroad access357Repository stars

1C OData MCP with a JSON cache

MCP сервер для работы с OData 1C

Russian stack

A Python MCP server over 1C OData: reads and changes catalogs and documents, saving everything to JSON files for local analysis without repeat queries

MCP serverBroad access4Repository stars
Russian stack

A Python proxy between an MCP client and a 1C HTTP service: reads metadata, object structure and predefined data, with optional OAuth2

MCP serverExtended access9Repository stars
Russian stack

A 1C extension that runs an MCP server inside the infobase: metadata tools out of the box and custom tools in BSL

MCP serverBroad access573Repository stars
Russian stack

A native component that runs a full MCP server inside 1C: tools, resources and prompts are written in BSL, while a DLL handles the protocol

MCP serverBroad access44Repository stars

1C metadata MCP server

1C_MCP_metadata

Russian stack

An MCP server over a 1C extension's HTTP service that exposes configuration metadata, searches objects and validates query syntax

MCP serverExtended access63Repository stars

README in short

The README itself is a single description line. The substance is in architecture.md and json_rpc_spec.md: the first describes the system components (user, LLM agent, Python middleware, 1C HTTP service), the data flow, security requirements (no direct SQL, JWT, HTTPS only) and the UUID conversion function; the second gives a full JSON-RPC 2.0 protocol spec with three methods and an error code table. The license is stated in the LICENSE file.

README badge

Report a problem