Gavin’s post called the “pipes” the second layer of the Mindset Stack. In this blog, I am going to detail those pipes.
What are the highlights?
– We have nine MCP servers running in production on BTP Cloud Foundry.
– They expose 144 tools across procurement, credit, sales, invoice reconciliation, supply chain, finance, plant maintenance, and warehouse delivery.
– Every Joule agent we ship is backed by one of these.
– The repo is in our GitHub, ready to accelerate customer pain points.
Next, let’s talk about how it actually works.
What is MCP?
Model Context Protocol is an open-source standard from Anthropic, released in November 2024, that lets an agent call tools without anyone hard-coding the integration. The agent reads the available tools, picks one, calls it, and gets a structured response. That’s it! S/4HANA already has thousands of OData APIs. MCP is the wrapper that turns those APIs into tools an agent can use.
The architecture
SAP BTP Build Joule Studio Agent → MCP Server (BTP Cloud Foundry) → Destination Service → Cloud Connector → S/4HANA on-prem.
Five steps, all of them already inside SAP’s path. The agent never touches S/4HANA directly. It calls our MCP server, our MCP server calls the destination, and SAP’s existing trust layer handles the rest. OAuth2 client credentials. Automatic CSRF token handling on OData V2. One BTP destination shared across all servers, so we are not configuring Cloud Connector for each new server we add.
Example architecture of an on-prem S/4 scenario:
The lesson on scope
Each MCP server is scoped to a single business domain. Procurement is one server. Credit is another. Maintenance is its own. We keep tool counts under 20 to 30 per server. The reason is not technical. It is that LLMs get worse at picking the right tool when you give them too many to choose from. A single agent backed by a 200-tool server is an agent that can easily pick the wrong tool and send back incorrect data or hallucinations. Smaller, domain-scoped servers is the design choice that made our agents reliable.
Tools building tools, on top of human expertise
The build loop is the part I get the most questions about. Drop an SAP OData API spec into the repo. Point Claude Code at it. It reads the spec, follows the conventions in our CLAUDE.md and docs/ folder, and produces a production-ready MCP server end-to-end. Templates, deployment workflow, BTP destination setup, all consistent.
This is what “with AI, on top of human expertise” means. The CLAUDE.md is not magic. It is the encoded result of everything Matthew Whigham figured out building the first four servers by hand. Conventions for naming. Patterns for CSRF. How we handle CRUD versus action endpoints in S/4HANA. The next server is faster because the last one taught us something. Each customer engagement we have done since 2010, every Fiori build, every Integration Suite migration, every BTP setup, all of that judgment lives in code and prompts now. The AI is the leverage. The expertise is ours.
The MCP Gateway in Integration Suite
The MCP Gateway in SAP Integration Suite is the on-ramp for non-SAP AI agents to call SAP APIs through the trust layer. For Mindset, it means the same architecture we use for our Joule agents extends cleanly to agents that are not Joule. Same governance, same auditability, same identity model.
The new SAP API Policy
API Policy v.4.2026a, published in late April. Every semi-autonomous agent invocation against an SAP API has to come through SAP-endorsed paths. Joule. Integration Suite. MCP Gateway.
Do I think this impacts our tools? No. We are already on those paths. The architecture above is exactly what SAP just told the ecosystem to build. Customers asking us right now whether their existing AI experiments will hold up under the new policy are getting a straight answer: if it is not on Joule, Integration Suite, or MCP Gateway, it is going to need rework.
The DSAG’s ask for clarification is fair. SAP needs to publish more on what counts as an “endorsed path” for SAP-to-non-SAP scenarios. Until they do, the safest position is the one we have been in for a while.
A2A, briefly
Not every agent lives inside SAP. The agent-to-agent patterns SAP and others are pushing matter for the cases where a Joule agent needs to coordinate with an agent in Salesforce, Workday, ServiceNow, or whatever else the customer runs. We are tracking it and we will build to it the same way we built to MCP. Pragmatically, one customer engagement at a time.
What is next
More servers, more use cases, more functional domain agents that help real people do real work in less time with less headaches. This is the evolution of User Experience we at Mindset have been waiting to showcase. As an ethos, we have always wanted to make employee’s lives better at work. Now, we can prove it with our tools and accelerators we use to get these employees to a happier/easier work life. The domain areas I have been pushing for are warehousing/EWM, plant operations and maintenance, asset management, and supply chain. Those are the SAP processes where we see the most operational pain on the ground and the place where SAP traditionally invests the least to help.
Interested in learning more?
Visit Mndset’s Linkedin
Visit Mindset’s Blog Library
Visit Mindset’s YouTube Page
