Custom MCP Servers: Why Is It Hard to Connect Business Systems to AI Agents?

Your team ships an MCP server in weeks. It reads a customer's SAP sales orders in a demo, and everyone's happy. Then the second customer connects, and half the tools return errors because their SAP instance is set up differently. The third customer's security team asks how you're validating token audiences. The fourth wants the agent to create records, not just read them, and now one bad tool call can post a duplicate invoice.

The protocol part was the week or two. Everything after is the actual work.

MCP, the standard that lets an AI agent call your product's tools, is deliberately simple. That simplicity is the point, and it's also why "just build an MCP server" hides how much sits underneath. Anthropic introduced MCP as a thin, open layer, not a full integration framework. If you're still deciding whether MCP is even the right layer for your product, start with MCP vs REST API. This article is about what breaks once you've decided to build.

---

Why is it hard to connect business systems to AI agents?

Because enterprise systems were built to be called by regular software, and an AI agent isn't regular software. It decides for itself, at the moment of each request, which tool to call and what to pass in. A traditional integration runs a fixed, tested path: this function calls that endpoint with these fields, every time. That one shift moves the hard problem from "can we reach the API" to "will the agent use it correctly, safely, and on the right customer's data."

On top of that, the systems themselves, SAP S/4HANA, NetSuite, Dynamics 365, Salesforce, Workday, Coupa, are some of the most customized software any company runs. Two customers on the same product rarely look the same underneath. So building a custom MCP server means solving several problems at once: getting a safe place to build, per-instance differences, authentication, tool count, write safety, and the quality of your tool descriptions. The rest of this article takes them one at a time.

What makes a custom MCP server hard to build?

Because you're exposing a customized enterprise system to an AI model that decides for itself how to use it. You reach for a custom server when off-the-shelf and unified connectors can't reach the data or actions your customers need, which, for enterprise systems, is most of the time. And with MCP the consumer is an AI model, so your tool descriptions become part of the product itself, not just documentation. A normal integration has a fixed contract you can test exactly; a custom MCP server has to hold up against an agent that makes its own choices.

Unified and pre-built connectors get you standard objects quickly, and for common cases they're a reasonable choice. The catch is that they expose one fixed, standardized schema, and enterprise customers live in the custom fields, custom objects, and write operations that a standard schema leaves out. As Merge points out in its writeup on ERP API integration, every ERP's API is different and heavily configured per customer. That's why the enterprise long tail still ends up custom every time, and why "we'll just use a connector" runs out of road the moment a customer needs something non-standard.

Why does every enterprise system need custom work?

Because enterprise systems are configured per customer, so the same product exposes different objects, fields, and rules at every company that runs it. A Salesforce org can carry dozens of custom objects and hundreds of custom fields. A NetSuite account is shaped by custom record types and saved searches. Every SAP instance is set up differently, which is why reads usually work off the shelf and writes almost never do.

The practical effect: a tool that passes every test in your own environment can still fail against a customer's live system, because a field that's optional for you is required for them, or a custom validation rule rejects the write. This is the single most common reason MCP timelines slip, and it isn't really a coding problem. It's a knowing-the-customer's-setup problem. Expect real per-customer configuration work on every enterprise deployment, and budget for it up front.

Why does sandbox access slow MCP projects down?

Because you can't safely build or test an MCP server against a customer's live ERP, so you need a separate sandbox that mirrors it, and getting one for a system like SAP or NetSuite can take weeks before you write a line of code. Enterprise vendors gate sandbox access behind approvals, partner programs, and licensing, and it often costs money to run. For many projects it's the single longest lead-time item, longer than the build itself.

That's why teams that already have environments ready can start on day one while everyone else waits. We keep our own sandbox environments for the major ERPs, including SAP S/4HANA, NetSuite, D365, Coupa, Workday and so on, so provisioning isn't the bottleneck. If you're building in-house, start the sandbox request early, because it rarely moves as fast as you expect.

Why is MCP authentication so hard?

Because a remote MCP server has to act as a full OAuth 2.1 resource server, and most teams underestimate what that involves. The MCP authorization spec makes the server a resource server that checks tokens rather than issuing them, and it has to implement Protected Resource Metadata (RFC 9728) so a client can find the right authorization server. Tokens have to be tied to a specific audience using Resource Indicators (RFC 8707), so a token made for one server can't be reused against another. Clients have to use PKCE, and tokens should be short-lived, so a leaked one is useful for minutes, not months.

Then reality doesn't match the spec. Dynamic Client Registration is the mechanism meant to let clients register on their own, but major identity providers such as Google, GitHub, and Microsoft Entra don't support it, so you end up registering clients by hand or building a proxy. And the wider ecosystem is behind: an Astrix Security analysis of more than 5,200 MCP servers found that 88% require credentials, over half rely on static API keys, and only 8.5% use OAuth at all. Getting authentication right adds 1 to 2 weeks when there's no existing OAuth provider to build on, and "we'll add auth later" is the decision that most often turns into a rebuild.

Do too many tools make an AI agent worse?

Yes, once you get past roughly two dozen. Every tool you expose takes up context and competes for the agent's attention, so beyond that point the agent starts picking the wrong one more often. This isn't a hunch. The RAG-MCP paper measured tool-selection accuracy of about 43% when only the relevant tools were shown to the model, versus under 14% when every tool description was dumped into the prompt at once, a threefold drop with the same model underneath. Even a handful of busy servers can eat a large share of the context window before the user has asked anything.

The fix isn't fewer capabilities, it's designing tools at the right level. One well-shaped create_sales_order tool beats five thin wrappers around raw database operations, because the agent has fewer, clearer choices to make. As a rough guide, 10 to 25 tools is a healthy first cut, enterprise servers reach 25 to 45 with grouping, and past about 25 you should watch selection accuracy and consider a search layer. Tool descriptions are prompts for the agent, not docs for a developer, which is a skill of its own, covered in designing MCP tools your agent won't misuse.

Why are MCP write operations risky?

Because an AI agent can call a write tool with the wrong arguments, at the wrong time, against a system where the action can't be undone. Reads are cheap and forgiving. Writes post invoices, create orders, and update master data, actions with financial and audit consequences. An agent that misreads the situation can duplicate a record or write to the wrong account, and in an ERP that's not a bug ticket, it's a finance problem.

Writes also depend on reads. Before creating or updating a record, a well-built write tool usually has to look things up first: the right customer ID, the open sales order to attach a line to, the account a payment belongs to. Enterprise objects are full of these dependencies, so an agent that writes without reading the surrounding data first tends to attach records to the wrong parent or skip a required link. Good write tools fetch and confirm that context before they commit anything.

For higher-risk systems we add a two-phase pattern: the tool prepares the change, a human reviews it, and a second call commits it. We add that where the risk warrants it, for example on S/4HANA writes, not as a blanket default on every server. Writes also run into rate limits. Most enterprise APIs cap how many calls you can make in a window, and an agent that retries on failure can burn through that fast, so write tools need queuing and idempotency to stay safe under load. It's why reads can ship in days while writes take real design work, the same lesson from our production S/4HANA MCP case study.

How long does an MCP server take to build, and what does it cost?

A production MCP server takes 2 to 4 weeks, or 1 to 2 weeks for fast delivery teams when scope and access are already well defined, and runs roughly EUR 5,000 to 15,000 depending on the system's complexity. The variance is almost entirely the challenges above, not the protocol. A modern SaaS API with clean OAuth lands near the fast end. A heavily customized SAP or NetSuite instance, with write operations and a security review, lands at the top.

The two things that most often stretch a timeline are sandbox access and per-customer configuration, both covered above. Inovaflow is about a year old, but the team has built these integrations for years in prior roles. Whether you build in-house or outsource comes down to one question: have your engineers done enterprise auth and per-instance write work before? That's where the weeks go, not the MCP boilerplate. If you're weighing that call, build in-house or outsource your MCP server walks through it, and a scoping call turns your API docs into a fixed quote and timeline.

---