Earlier this month, a detailed technical article on Habr caught the AI community’s attention. The team behind Bitrix, a major collaboration platform, shared a frank account of why they chose the Model Context Protocol (MCP) for their AI agent — and why that decision turned out to be a game-changer. Source
If you’ve been following the world of AI agents, you know the hype. But hype aside, there’s a real, practical problem: AI models are trapped inside a context window. They can’t access your databases, call your APIs, or actually do things — unless you give them a way out. MCP is that way out.
In this article, we’ll unpack what MCP is, why the Bitrix developers picked it over alternative approaches, and what you can learn from their experience — whether you’re building your first agent or scaling a production system.
The Problem: AI Agents Need More Than a Brain
Large language models (LLMs) are brilliant at generating text, but they’re terrible at acting on the world. An agent that can’t check your calendar, send an email, or query your CRM is just a fancy chat widget. The authors describe this as the "context ceiling": no matter how long your prompt is, the model remains isolated from your systems.
The obvious solution is to connect the model to tools. But how? Before MCP, every integration required custom glue code. You wrote an API endpoint, wrapped it in a function, taught the model to call that function, and repeated the process for every new service. It worked — but it was messy. The Bitrix team felt this pain firsthand when building agents for their own platform.
What Is MCP? A Quick Primer
MCP — the Model Context Protocol — is an open standard that defines how AI models talk to external tools and data sources. Think of it as USB-C for AI. Instead of writing a different adapter for each service, you implement a single protocol that any MCP-compatible client can use.
At its core, MCP separates the client (the AI model) from the server (the tool or data source). The server exposes capabilities — like “search database”, “send message”, or “run SQL query” — in a structured way. The client discovers those capabilities and calls them with consistent JSON-RPC messages. It’s clean, unopinionated, and already supported by major players like OpenAI and Anthropic.
For the Bitrix developers, this meant they could stop building one-off connectors and instead create reusable MCP servers. Need a new integration? Write an MCP server once, and every agent benefits.
Why the Bitrix Team Chose MCP
The article doesn’t just praise MCP — it walks through a careful decision process. Here’s why they ultimately said yes to MCP, based on the published rationale.
1. Standardization Beats Ad-Hoc Integration
Before MCP, the team had experimented with “function calling” — a built-in way to let the model choose a function to execute. It worked for simple cases, but it quickly became a nightmare. Each tool required a schema, testing was tedious, and sharing tools across projects was impossible.
MCP solves this with a uniform contract. A database tool and a Slack tool both speak the same protocol. The article highlights that the same MCP server can be used to plug into both a local dev environment and a cloud deployment, without touching a line of code. That’s a huge win for maintainability.
2. Security by Design
One of the biggest fears with AI agents is that they’ll run wild. Bitrix’s article emphasizes that MCP lets you define scoped permissions for each tool. An agent may be allowed to read from a database but not write to it. The server controls access, not the model — a crucial safety boundary.
The authors also appreciated that MCP supports human-in-the-loop approval. Every tool call can be gated behind a confirmation step, which they found essential for actions like sending emails or modifying customer records. In a collaborative platform like Bitrix, this literally saves you from an embarrassing AI mishap.
3. Ecosystem Momentum
The tide has turned. By 2026, MCP is no longer an early-adopter toy. The article points to widespread adoption across AI IDEs, automation platforms, and enterprise software. The standard’s governance is in good hands, with input from across the industry, and the pace of new connectors is staggering.
For Bitrix, riding this wave meant they didn’t have to build everything in-house. They could rely on a growing ecosystem of pre-built MCP servers — and focus their engineering effort on their core product.
A Simple MCP Implementation Example
No article on MCP would be complete without a peek under the hood. The Bitrix team documents a minimal MCP server configuration in their post. Here’s how you’d paint the picture:
{
"mcpServers": {
"charting": {
"command": "node",
"args": ["chart-server.js"],
"env": { }
},
"salesforce": {
"command": "npx",
"args": ["mcp-server-salesforce"],
"env": {
"SALESFORCE_TOKEN": "$FROM_SECURE_STORE"
}
}
}
}
In this snippet, two MCP servers are registered with a client. The first runs a custom script that generates charts; the second launches a community-maintained Salesforce connector. The client reads this config at boot and exposes the servers’ tools to the AI automatically.
The key takeaway: integration is declarative, not imperative. You don’t write REST calls; you define a server and let the protocol handle the rest.
Practical Tips for Adopting MCP
Based on the article’s experience, here’s a quick list of actionable advice:
- Start with a standard server. Before building your own, check if an MCP server already exists for the tool you need. The ecosystem includes connectors for databases, messaging, file systems, and more.
- Use secure credential storage. MCP allows environment variables, but don’t hardcode secrets. The Bitrix team used a vault-backed approach.
- Design for failure. Add timeouts and retries. The article warns that MCP calls over a network can be slow; treat them as remote requests, not local calls.
- Test in isolation. Before letting an agent loose on production tools, spin up a sandbox environment. Your engineers’ local machines are a good place to start.
Challenges You’ll Still Face
MCP is not a silver bullet. The Bitrix developers encountered real challenges:
- Latency. Each tool call adds a network round-trip. For queries that need five sequential tool calls, that adds up. They recommend parallelizing independent calls.
- Tool selection. Giving an agent too many tools can confuse it. The article shares that they had to curate tool lists per context to improve response quality.
- Debugging. With multiple servers, tracing a single request becomes harder. They invested in logs and tracing early — a move they call “expensive but necessary.”
The Verdict: Why MCP Was the Lucky Bet
Looking back, the Bitrix team is unequivocal: MCP was the right call. It simplified their architecture, unlocked a wider ecosystem, and — critically — future-proofed their agents. In an industry where AI frameworks change every few months, MCP’s stability is a rare asset.
Whether you’re a startup founder or a developer at a large enterprise, the lesson is clear: when building an AI agent, don’t reinvent the integration wheel. Adopt a standard protocol, embrace its limits, and you’ll move faster than you thought possible.
So, what about you? Have you tried MCP for your own agents? The Bitrix case study is a great starting point — read the full article on Habr for deeper insights and a look at the exact code they shipped. One thing its certain: the era of bespoke AI integrations is over.
Comments