Building a Production S/4HANA MCP Server: A Case Study

This is a case study of one of our recent engagements — the first we’re publishing in detail. If you’re weighing whether to build an MCP server for S/4HANA yourself, whether to outsource it, or what the work actually involves when you do, this is meant to be useful. We cover what was straightforward, what wasn’t, where previous work carried over, and where it didn’t.

---

Context: the client and what they were building

For this case study we’ll call the client Agentic SaaS — we’re still finalizing the official partnership and the legal right to use their real name, so this stays anonymous for now, but everything below is real.

They’re a B2B SaaS company shipping an AI agent product to enterprise buyers. Their agent needs real-time read and write access to whatever enterprise systems their customers run — CRMs, ERPs, ticketing, finance. SAP S/4HANA was one of the flagship systems on their roadmap.

Their engineering team is strong, but enterprise APIs aren’t their core competency, and they had no clean path to an S/4HANA sandbox. They came to us with a clear ask: handle the MCP side end-to-end so their team could stay focused on the product.

We’d already built MCP servers for other ERPs for them. S/4HANA was the next one.

---

Why MCP tool design for S/4HANA is different from an API integration

Inovaflow is about a year old, but our team members have been building SAP integrations for years in previous roles. S/4HANA wasn’t new to us — the OData endpoints, the authentication flows, how to handle pagination, how money fields need their paired currency key — all of that was familiar. Our sandbox access was already live.

The part that was different: this wasn’t an API integration. It was an MCP server. That sounds like a small distinction. It isn’t.

A REST integration gets called by code. Your code knows which endpoint to hit, with which parameters, in which order. An MCP server gets called by an AI agent — which decides what to call, when, and how, based on what the user asked. That changes the design of the tools completely. The tool descriptions aren’t documentation; they’re part of the agent’s prompt. The parameter schemas aren’t validation rules; they’re instructions the agent uses to construct arguments. The error messages aren’t for developers; they’re for the agent to decide whether to retry, re-prepare, or ask the user.

We knew this going in. What we underestimated is how much of our existing S/4HANA MCP work would need to be rewritten around their specific agent.

---

What we built

Across the engagement:

• A production MCP server covering read tools (list customers, suppliers, purchase orders, invoices, inventory, and more) and write tools with two-phase confirmation (create and update customers, post invoices, create purchase orders)
• Normalized error envelope across all tools so the agent could respond predictably to auth failures, validation errors, rate limits, and conflicts
• File-based responses for any tool that could return more than a handful of records, with an index file the agent reads first to orient itself
• OAuth 2.0 client credentials flow with proactive token refresh and per-account locking
• Public-facing setup documentation for Agentic SaaS’s own customers, explaining how to configure their S/4HANA instance so the MCP can connect correctly
• Pre-deployment setup support for their prospects during POCs, working directly with prospect SAP admins to get instances configured

Full source code, documentation, and runbooks transferred on handoff.

---

What carried over from previous S/4HANA work — and what didn’t

Roughly 60% of the groundwork carried over. The auth layer. The pagination wrappers. The field-level transformations for money and dates. The retry and backoff logic. The test harnesses against our sandbox.

The other 40% — the tool layer — was largely new.

We’d built tool definitions for S/4HANA before, but those were shaped by a different client’s agent. Their agent reasoned differently. It scoped queries differently. It recovered from errors differently. Tool descriptions that worked well in the previous engagement caused this agent to pick the wrong tool or construct malformed arguments.

So we rewrote. We tested against their actual agent behavior, watched where it misfired, and tightened descriptions until hit rates were consistent. We added disambiguation where we previously had none. We split a few tools that had been merged in the last engagement, and merged others that had been split.

The honest lesson: MCP servers aren’t as reusable across clients as API integrations are. The system-facing half of the work compounds beautifully across projects. The agent-facing half doesn’t. Anyone claiming otherwise probably hasn’t shipped two MCP servers for the same system to two different AI products.

---

S/4HANA instance variance: the part clients need to be ready for

This one isn’t new to us — it shows up in every SAP integration — but it still caught Agentic SaaS’s customers off guard, so it’s worth being explicit about.

There is no such thing as a standard S/4HANA instance. Every customer’s configuration differs in ways that matter:

• The S/4HANA release version itself, and which SAP Notes (SNOTE) have been applied — behavior can change meaningfully between support packages
• Which CDS views they’ve extended and which fields they’ve added
• Which business partner roles they use and how those map to your concept of “customer”
• Which sales document types, billing types, and pricing procedures they’ve configured
• Which authorization objects their communication user has access to
• Whether they use extension fields, custom BAPIs, or parallel custom tables for data you’d expect in the standard schema

Because of that variance, every customer’s onboarding includes a short configuration step on their side. That’s not a flaw in the architecture — it’s what S/4HANA is. And it’s why having someone on your side who actually understands S/4HANA deeply matters. Agentic SaaS’s customer success team runs that step as part of standard activation now, but that wasn’t the case at the start. Early on, we were pulled into most customer activations to help map fields, validate authorization setup, and resolve the inevitable “our SAP team says this looks wrong” questions. Over time we documented enough of the patterns, wrote the setup guides, and trained their team so they could run most activations independently — with us as backup for the edge cases that come up with specific customer configurations.

If you’re planning a build like this, bake that reality into the design from day one.

---

Two-phase confirmation: more work, fewer mistakes

For write operations on this engagement, we use a two-phase confirmation pattern: the agent calls a prepare_* tool that validates inputs and returns a preview plus a single-use token, the user reviews and approves, then the agent calls confirm_action to execute.

The previous ERP MCP we built for Agentic SaaS didn’t use this pattern. Writes went directly — the agent called a tool, the change was made, done. Simpler, faster, and it worked fine for that system.

For S/4HANA, they wanted a different level of accuracy and the lowest possible risk. S/4HANA writes can be destructive when fields are missing, and the customers hitting production are enterprises where a bad posting has downstream effects. So we added the human-in-the-loop step. Slightly more involvement for the user — they see a preview and confirm — in exchange for significantly more reliable and auditable results.

The hardest part wasn’t the two-phase pattern itself. It was handling the window between prepare and confirm. What happens if someone else modifies the record in SAP while the user is reviewing the preview? What happens if authorization changes between the two calls? What happens if the preview expires? None of that existed in the previous MCP we built for them. We worked through it on this one.

Whether the next MCP needs this pattern or not is going to depend on what the SaaS is optimizing for — speed, user friction, auditability, reversibility. Expect write operations in enterprise contexts to need a thoughtful approach. Expect it to look different each time.

---

Helping their customers set up S/4HANA on their side

One of the less-expected parts of the engagement: writing the public-facing setup documentation, and advising Agentic SaaS’s own customers on how to configure their S/4HANA instance.

Their customers — large enterprises — needed instructions on which communication scenario to provision, which authorization objects to assign, how to set up the OAuth client, and which sample transactions to run during activation to confirm the connection worked. We wrote that. Agentic SaaS reviewed, branded, and published it. Their customer success team now walks prospects through it during activation.

We also took direct calls with prospects during POCs — usually with the prospect’s own SAP Basis admin — to debug setup issues. “Your communication user is missing authorization for object S_RFC, here’s the SAP Note that covers it.” Most B2B SaaS sales teams don’t have that conversation sitting ready internally. We did.

This wasn’t the part that showed up on the SOW, but it’s where a lot of the engagement’s real value landed. Deals that would have stalled on “we couldn’t get our SAP team to configure it” closed because someone on our side could talk to their SAP team directly.

---

What we did well

• Sandbox access was a non-issue. We started building day one. Agentic SaaS’s internal estimate had been 4–6 weeks before any code could be written. We started the same week.
• Treated tool descriptions as agent-facing UX, not API docs. The iteration loop was: write, watch the agent use it, adjust. That discipline is what separates a demo from production.
• Test, test, and test. Like most integrations, MCP is no different — almost half the job is testing, verifying, modifying, improving. Two of our engineers worked testing in parallel on different angles: one on happy-path tool calls against realistic customer data, the other on edge cases, auth failures, and adversarial agent prompts. Having two people testing at the same time meant one caught what the other missed. That overlap is what kept bugs out of production, not luck.
• Defaulted to two-phase confirmation for write operations. Agents occasionally construct arguments that aren’t quite what the user meant. Catching that at prepare time is cheaper than rolling back SAP records.
• File-based responses for large result sets. Kept the agent’s context window clean, kept latency predictable.
• Kept Agentic SaaS’s engineering team completely off the integration layer. They stayed on the product. That was the point, and we held the line on it.
• Customer-side setup support during POCs. Closed deals that would otherwise have stalled on the prospect’s SAP configuration.

---

Where experience actually matters

Experience isn’t knowing the OData spec. That’s public. Anyone with three weeks, a Claude paid subscription, and access to documentation can work through it.

Experience is in the things that aren’t documented:

• Knowing how the SAP Partner Program sandbox process actually works — the specific sequence, the specific contacts who actually respond, and the reality that without prior relationships it typically takes months to get production-ready access
• Knowing how to work effectively in the SAP GUI — navigating transactions, reading dumps in ST22, checking authorization traces in SU53, running SE16 to verify what actually landed in a table
• Knowing what to test before building — running BAPI_* transactions manually in SE37 to understand behavior before you wrap them, confirming communication scenarios work in SCC4 before writing the OAuth layer
• Knowing which authorization objects block standard reads before your first 403 tells you
• Knowing the common gotchas: that BAPIs sometimes swallow errors and return success, that certain OData services require specific gateway registrations, that client numbers matter more than you’d expect, that partner function configuration can make a “simple” customer lookup return nothing
• Knowing how field-level customization will break your “one server per system” abstraction — before it breaks
• Knowing that AI agents generate traffic patterns nothing like a cron job, and sizing your rate limit strategy accordingly
• Knowing that the tool descriptions that worked for the last agent probably won’t work for this one, and building iteration time into the plan
• Knowing that prospect SAP admins will ask questions during POCs that nobody on the SaaS side can answer, and being the person who can

None of that lives in a repo. It lives in the accumulated scar tissue of shipping these systems and watching them behave in production. That’s the part you’re buying when you work with a team that’s done this before.

---

Takeaways for anyone planning an MCP build for S/4HANA

1. The system-facing work compounds across projects. The agent-facing work doesn’t. Budget iteration time for tool descriptions against your actual agent.
2. S/4HANA instances vary — by release, by configuration, by customization. Accept that some operations will need per-customer configuration and design the server around that from day one.
3. Write operations are sensitive in enterprise contexts. Expect different approaches for different systems — direct writes, two-phase confirmation, queued approvals — and pick based on what the SaaS is optimizing for.
4. Your customers will need setup guidance on their side. That documentation is part of the deliverable, not an afterthought.
5. The people you send into POC conversations matter as much as the code. Someone who can talk to the prospect’s SAP admin closes deals your sales team otherwise loses.

If you’re weighing whether to take this on internally or work with a partner, our build-or-outsource guide for MCP servers walks through the trade-offs in more detail.

---