A self-adapting Bitrix24 MCP server

The problem

An LLM was wired into a live CRM to read and write real records on behalf of a team. The catch: the CRM’s schema was not fixed. Fields were added, renamed, and reconfigured by administrators while the system was running. Ordinary CRM housekeeping, but enough to move the ground under any integration built on top of it.

A hardcoded integration assumes the schema it was written against. The moment a field changes, its assumptions are stale: tool definitions point at fields that no longer exist, and calls fail or, worse, silently write to the wrong place. The integration doesn’t bend; it breaks, and it breaks quietly.

The approach

Rather than encode the schema, the server reads it. On startup, and on demand, it introspects the CRM over its REST API, discovers the current set of entities and fields, and generates its MCP tool surface from what it finds. The tools the LLM sees are a function of the schema as it actually is, not as it was when the code was written.

When the schema drifts, the next introspection picks up the change and the tool surface regenerates to match. The model is always handed an accurate map. Adaptation is the default behavior, not a maintenance task.

The design decision that mattered

The decision was to treat schema drift as the expected condition, not an edge case. It would have been faster to introspect once at deploy and cache the result. That would have worked, until the first change. Building the introspection into the runtime path cost more up front and bought resilience that pays back every time an admin touches a field.

Concretely: the source of truth for the tool surface is the CRM, not the codebase. That inversion is the whole design. Everything downstream, error handling, validation, the LLM’s view of the world, follows from refusing to hardcode what the CRM already knows about itself.

Failure handling

TO BE WRITTEN. How the server behaves when introspection fails, the API is unavailable, or a generated tool maps to an invalid field: degradation strategy, retries, and what the LLM is told. Placeholder, to be filled in with the real handling.

Impact

TO BE WRITTEN. Business impact in true terms: what the team could do that it couldn’t before, and the maintenance it removed. Placeholder, no numbers invented here.

A note on scope: this ran in an internal, low traffic environment. It has not been adversarially load tested at scale.