Wire every model to every system by hand, or expose each system once through a protocol any model can speak
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.
Last updated:
Custom integration means writing a connector for each pairing: this model, that system, these credentials, this schema. It works, and for one or two systems it is the fastest thing to do.
The Model Context Protocol inverts the arrangement. Each system is exposed once as an MCP server describing its tools and resources, and any MCP-capable model can call it. The system is integrated with the protocol rather than with a particular model.
The difference is arithmetic. Bespoke connectors scale with models multiplied by systems. MCP scales with systems added to models. At three of each the two are comparable; at ten of each one approach has thirty times the maintenance surface of the other.
This page covers where that arithmetic starts to bite, what MCP does not solve, and when a hand-written integration is still the right answer.
by ibl.ai on the open protocol
Standard interface between models and systemsby Your engineering team
Bespoke per-model, per-system connectors| Criteria | MCP | Custom API Integrations |
|---|---|---|
| Integration Count | One server per system, reusable by every model — integrations grow additively. | One connector per model-and-system pairing, so the surface grows multiplicatively. |
| Cost of Adding a New Model | Near zero. A new model speaks the same protocol and inherits every existing tool. | Re-implement the connector layer against the new model's tool-calling conventions. |
| Cost of Adding a New System | Write one server; every agent and model gains access immediately. | Write it once per model that needs it, and keep each copy in step over time. |
| Ongoing Maintenance | An upstream API change is fixed in one server rather than in every connector that touched it. | Schema drift propagates into every bespoke connector, and they break at different times. |
| Criteria | MCP | Custom API Integrations |
|---|---|---|
| Fit to Unusual Systems | Servers can wrap almost anything, but a legacy protocol needs that wrapper written first. | Unbounded. A bespoke connector can do whatever the system permits, however strange. |
| Permissions and Scoping | Tool-level scoping in one place, so what an agent may do is defined and audited centrally. | Enforced separately in each connector, which is where inconsistencies accumulate. |
| Discoverability for Agents | Servers describe their own tools, so an agent can discover capability at runtime. | Capability is hardcoded; the agent knows only what its prompt was told about. |
| Latency Overhead | A thin protocol layer adds a small hop, immaterial for most workloads. | Direct calls with nothing in between are marginally faster. |
| Criteria | MCP | Custom API Integrations |
|---|---|---|
| Model Portability | Switching models does not touch the integration layer, so model choice stays reversible. | Integrations are written against a model's conventions, which quietly cements that choice. |
| Ecosystem Reuse | Existing servers for common systems can be adopted rather than written. | Everything is yours to write and yours to keep working. |
| Audit Surface | Tool calls flow through one layer, producing a consistent, complete log. | Logging quality varies per connector, which makes reconstructing an incident harder. |
| Time to First Integration | Slight upfront cost to stand up the server layer before the first tool works. | For a single system and a single model, a direct call is the fastest path there is. |
With MCP the surface is systems plus models. Ten systems and four models is fourteen things to maintain, and adding a fifth model costs nothing.
With bespoke connectors the surface is systems times models — forty implementations for the same estate, each with its own credentials, schema handling, and failure modes.
Below roughly three systems the difference is noise. Past that, the multiplication is what turns an AI integration project into permanent maintenance.
The protocol standardizes how tools are described and called, and gives you one place to scope permissions and log activity.
Neither approach decides who may see which record. Permissions-aware retrieval, identity propagation, and audit remain your responsibility either way.
Adopting MCP does not make an agent safe. It makes the controls you still have to build enforceable in one place instead of forty.
A server is a wrapper, and a genuinely strange legacy interface needs that wrapper written before anything works.
For one system, one model, and a stable requirement, a direct integration is less code and less indirection. Not every problem needs a protocol.
Use direct integration for a single high-value system you control. Adopt MCP the moment a second model or a third system appears.
Each additional model multiplies bespoke connector work but adds essentially nothing to an MCP estate.
A direct integration is less code and fewer moving parts when the requirement genuinely will not grow.
Routing every tool call through one layer produces a uniform audit trail instead of connector-by-connector logging of varying quality.
Integrations written against one model's conventions are a quiet form of lock-in; a protocol layer keeps the model swappable.
Timeline: Two to six weeks depending on the number of systems
Timeline: Days to weeks per system
ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.
ibl.ai treats MCP as the integration layer rather than a feature. Each of your systems is exposed once, and every agent and model on the platform can reach it under scoped permissions with every call logged. That keeps the model layer genuinely swappable: because integrations are written against the protocol instead of a provider's conventions, changing which model serves a workload never touches the connectors underneath. Agentic OS runs this entirely inside your perimeter, so agents reach your systems of record without your data crossing a vendor boundary. You own all the code and the data, and can deploy on any cloud, on-premise, or air-gapped.
Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours.
Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform.
Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ.
Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
See how ibl.ai deploys AI agents you own and control—on your infrastructure, integrated with your systems.