How to build an MCP server for SAP Business ByDesign
Short answer
An MCP server for ByDesign is a small service that exposes a handful of read-only tools, each backed by a custom OData service or a communication-scenario web service, and authenticates to the tenant with a technical user. Any MCP client, including Claude and ChatGPT, can then query ByDesign through it.
The Model Context Protocol is a standard way for an AI client to discover and call tools. Instead of writing a bespoke plugin for every assistant, you write one server that describes what ByDesign can do, and every compatible client can use it.
For ByDesign this fits well because the platform is already built around explicit service exposure. Nothing is callable until a communication arrangement activates it, so your MCP tool list is a direct mirror of what you chose to open.
This page is about the server itself: design, tools, authentication, transport, permissions and audit. It is deliberately practical and avoids assuming any particular language, though TypeScript and Python both have official SDKs.
What teams use it for
Order and delivery lookup
Tools like get_sales_order and list_open_deliveries let any MCP client answer 'what is shipping this week' with live data.
Procurement visibility
get_purchase_order, list_overdue_purchase_orders and get_supplier_performance give buyers conversational access without opening multiple work centers.
Stock and availability checks
get_stock_by_material and check_availability for planners and customer service, with warehouse and site as parameters.
Finance drill-down
list_open_supplier_invoices and get_document_flow help a clerk trace an item from order to payment.
Master data validation
search_material and search_business_partner support duplicate checks during onboarding or data cleanup.
Project and service tracking
For project-based businesses on ByDesign, get_project_status and list_time_entries surface progress and effort data.
SAP Business ByDesign integration surface
- Custom OData services built from analytics data sources in the Custom Services area: each becomes one tool with typed filters and a stable response shape.
- Standard SOAP web services in the Service Explorer, activated by communication scenarios. Use for lookups that custom OData does not cover; names and operations vary by release.
- Communication system with technical user and authentication by basic credentials or client certificate. This is the identity the server uses.
- Business roles and work center access restrictions on that technical user, which cap what any tool can return even if the server has a bug.
- Cloud Applications Studio extensions when you need a custom action exposed as a controlled write.
How it works
- 1
List tools by question, not by object
Start from ten real questions your users ask and design a tool for each, rather than mirroring every business object.
- 2
Build or select the ByDesign data sources
Create the analytics data sources and custom OData services, with only the needed fields. Test with the technical user in a REST client.
- 3
Scaffold the server
Use the official TypeScript or Python SDK. Register each tool with a name, a precise description and an input schema.
- 4
Implement the backend call
Translate input to OData filters or a SOAP request, handle paging, and return compact JSON with document IDs and status text.
- 5
Pick the transport
Use stdio for local single-user testing. Use streamable HTTP behind an identity-aware proxy for shared use, with TLS and per-user tokens.
- 6
Add auditing and rate limits
Log tool name, arguments, caller identity, duration and result size. Limit calls per user per minute.
- 7
Test with several clients
Connect Claude Desktop, an inspector tool and one other client, and write regression tests for every tool.
Example flows
Where is this customer's order
Trigger: A user asks any MCP client about a customer's recent order.
- Client lists tools and chooses search_sales_orders with the customer name.
- The server queries the custom OData service with a filter and a result cap.
- It returns IDs, status and requested dates.
- The client calls get_sales_order for the one the user means.
Result: A confirmed answer from live data with every figure traceable to a document ID.
Overdue purchase orders for a supplier
Trigger: A buyer asks which of a supplier's orders are late.
- Client calls list_overdue_purchase_orders with the supplier ID.
- Server filters on confirmed delivery date before today and open quantity.
- It returns lines with days late.
- Client summarises and suggests who to chase.
Result: A ranked list ready for a phone call.
Keeping data on-prem
ByDesign is hosted by SAP, so the MCP server is the piece you can place anywhere you like. Running it in your own data centre or private cloud means the credential, the audit log and the shaping logic stay under your control, and it calls the tenant outbound over HTTPS. Pair it with an open-weight model served with vLLM or Ollama and an MCP-capable client inside your network, and no ERP content has to reach a hosted model at all. If you use a hosted client such as Claude, the server can still sit on your side and return only minimal fields.
Security checklist
- Tools are read-only by default; each write tool needs a separate review and a draft-and-approve design.
- Scope the technical user's business role tightly so the platform itself enforces limits.
- Authenticate every client to the server and pass user identity into the audit log.
- Validate tool inputs strictly and never build OData filters by string concatenation from model output.
- Treat tool descriptions and returned text as untrusted; free-text fields such as notes can contain prompt injection.
Ways to get it done
Open-source or community MCP server
Effort: Days to adapt, with review needed.
Worth checking for a generic OData or SAP server, but expect to adapt field names and security to your tenant.
Build your own with the official SDK
Effort: One to three weeks for a first set of read tools.
Fits teams with API experience wanting full control.
Netray-built, governed MCP layer
Effort: A scoped engagement of a few weeks.
Fits teams wanting audit, role mapping and a private model path included.
Pitfalls
- !Offering one generic run_query tool. It defeats permission scoping and invites runaway queries.
- !Vague tool descriptions that make the model pick the wrong tool or invent parameters.
- !Returning free text from note fields straight to the model without sanitising.
- !Skipping paging, so one call pulls thousands of rows and breaks the client.
- !Forgetting service changes after SAP releases; keep contract tests for each tool.
Frequently asked questions
Is there an official MCP server for SAP Business ByDesign?
I am not aware of an official one, and the ecosystem moves fast, so check current registries. Most teams build a small server of their own over custom OData services, which keeps the tool list aligned to their questions.
Which transport should I use?
Use stdio for local development and single-user desktop setups, since it needs no network exposure. Use HTTP with TLS and an identity-aware proxy when several people or applications share the server.
Should the server allow writes?
Start without them. If you add writes later, expose narrow draft-creating actions, require a human to approve, and execute through a separate credential with minimal rights.
Does the same server work with ChatGPT and Claude?
That is the point of the protocol. Any client that supports MCP can use it, though client capabilities and remote-server support differ, so test each one you plan to rely on.
How do I stop the model from reading too much?
Limit tool outputs to needed fields, cap rows per call, scope the technical user's role, and rate-limit per user. Platform-level role restrictions are your last line even if the server has a flaw.
More for SAP Business ByDesign
Want MCP server working on your SAP Business ByDesign?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment