SAP OData MCP server: four ways to expose OData to an agent
As of 2026-10-18
Exposing SAP OData to an AI agent is the most common MCP pattern, and it has no single official server. Our catalogue (18 October 2026) lists four routes: a community OData-to-MCP server for BTP, the AWS for SAP MCP server, the Gavdi CAP MCP plugin for your own CAP services, and SAP Integration Suite MCP server artefacts built on your APIs.
The four routes
SAP OData to MCP on BTP — Maintainer: community, MIT · How: Node server for Cloud Foundry exposing S/4HANA or ECC OData services through three discovery-and-execute tools · Transport: both.
AWS for SAP MCP Server — Maintainer: AWS · How: container on Amazon Bedrock AgentCore, HTTP, discoverable OData V2 and V4 access with service discovery, reads, optional writes, function imports and allow-listing.
CAP MCP Plugin by Gavdi Labs — Maintainer: vendor, Apache-2.0 · How: generates an MCP server from annotated CAP services, served on a local /mcp HTTP endpoint · Scope: services you build in CAP, not generic S/4HANA.
Integration Suite MCP server artefact — Maintainer: SAP · How: built from API artefacts, OpenAPI-described HTTP endpoints or third-party MCP servers, with governed tools, resources and prompts.
Why three tools can be enough
The community server exposes only three discovery-and-execute tools rather than one tool per entity set. The assistant first discovers which services exist, then executes calls against them. That keeps the tool list short, which helps client performance, but it moves control from tool design to runtime parameters: the model composes the OData request itself.
The per-tool design of a CAP plugin or an Integration Suite artefact is the opposite trade. You decide what each tool does, name it, and describe it, so the contract is reviewable and versionable.
Development-time servers are a different job
Do not confuse these with SAP's Fiori MCP server, which helps an assistant create and change Fiori apps and can generate Fiori elements apps for CAP or OData projects and fetch service metadata. The CAP MCP server offers a fuzzy search over the compiled CDS model and a documentation search, and its README says the tools are not a stable API. They help you build apps; they are not a runtime data path.
What to check before production
Read versus write: OData supports create, update, delete and function imports; decide which are reachable and begin with none. Allow-list: restrict to named services and entity sets. Identity: for on-premise S/4HANA our notes record principal propagation through Cloud Connector, and for Public Cloud the OAuth2 SAML bearer assertion; a shared technical user loses the authorisation checks and the audit trail. Volume: guard against unbounded reads, since an assistant can request whole entity sets. Audit: log request path, parameters and user.
Policy: SAP's API policy, as summarised in our notes, limits agentic use of SAP APIs to SAP-endorsed architectures. A community server on Cloud Foundry is your architecture, not SAP's; check with your account team.
Finally, test failure modes: an expired token, a service that is removed from the allow-list, a malformed filter. An agent that retries blindly against a backend can create load or duplicate postings if writes are enabled.
Relation to Joule and agent platforms
Joule Studio lets you attach MCP servers to a Joule agent, and an MCP server on the Integration Cell runtime can be registered in Joule Work Desktop (part of SAP's Early Adopter Care programme, not generally available). For these, the Integration Suite gateway is the governed front: it applies authentication, rate limiting and monitoring and requires the Premium or Enhanced edition plus the Integration Cell runtime.
A modest, defensible pattern is: start with read-only, allow-listed services behind a gateway; add writes only for specific, approved actions. For market data rather than your own OData, the Analytics Legends MCP offers read-only public tools.
What we cannot assert
Write behaviour of the community OData server is not detailed in the catalogue.
Frequently asked
Is there an official SAP OData MCP server?
SAP's official route is an MCP server artefact in Integration Suite built on your APIs. A standalone OData server from SAP is not in our catalogue.
Can the assistant write through the community server?
The catalogue says it exposes discovery-and-execute tools; the write behaviour is not detailed. Test and restrict by service.
What is the AWS for SAP MCP server?
A container run on Bedrock AgentCore giving agents OData V2 and V4 access with allow-listing and optional writes and function imports.
Do I need Integration Suite?
Only for the governed gateway route, which needs the Premium or Enhanced edition and the Integration Cell runtime. Other routes do not.
Engage the editor
This guide is written by Cédric Mary, SAP AI & Analytics Architect & Team Lead. 27 years of SAP — Datasphere, Business Data Cloud, SAC Planning, Joule. Freelance or permanent · Hybrid / remote · Anywhere in EMEA. Available from 19 October 2026.
What this page is built on
- MCP — Model Context Protocol in SAP (mechanics)
- MCP for SAP — Adoption & Integration Strategy
- SAP OData to MCP on BTP (community) — GitHub
- AWS for SAP MCP Server — AWS documentation
- CAP MCP Plugin (Gavdi Labs) — GitHub
- SAP Fiori MCP Server — GitHub
External sources
- SAP OData to MCP on BTP (community) — GitHub
- AWS for SAP MCP Server — AWS documentation
- CAP MCP Plugin (Gavdi Labs) — GitHub
- SAP Fiori MCP Server — GitHub
- Model Context Protocol — specification changelog, revision 2026-07-28
- Model Context Protocol — Authorization (2026-07-28)
Read next
- SAP MCP server for SAP AI & analytics data
- SAP MCP servers list: what exists, who maintains it, what it does
- SAP S/4HANA
- Clean Core Principle
- MCP Server Architecture — Tools, Resources, Prompts
Guides that answer with this page
These guides cite this page as one of the sources their answer rests on.