CGR MCP Server for SAP lets a person work in SAP ECC 6 or S/4HANA by asking an AI assistant in plain language, under their own SAP user and authorizations, with no SAP GUI, no transaction codes and no Fiori app to build.
Thirty years of learning SAP
Using SAP has always meant learning SAP. Transaction codes, screens, Fiori tiles, the right field in the right place. Companies train people for months, and most of them still ask a colleague which transaction to use.
The knowledge that matters to the business is what the person needs. The knowledge SAP demands is where it lives. Those are different skills, and the second one is the expensive one.
What asking looks like
The user types or says what they need, in business terms:
- "Create a sales order for Smith Inc., one P-103 pump and one P-104, delivery today."
- "Which customers in company code 1000 are more than 60 days overdue?"
- "Run the stock report for plant 1000 and put it in Excel."
- "Where is order 19205? Has it shipped, and has it been invoiced?"
The assistant does the work in SAP and reports what SAP said back. The user never names a table, a BAPI or a transaction.
A real session: from customer order to posted invoice
In CGR's SAP ECC 6 demo system, a handful of sentences took one customer order from sales order to posted invoice. The user typed requests; SAP created the documents.
| What the user asked | What SAP did |
|---|---|
| Create a sales order for Smith Inc.: one P-103 pump and one P-104 pump, delivery today | Sales order 19205, confirmed and priced at $7,401.00 |
| Create the delivery | Delivery 80018926 |
| Pack it on pallets | Two handling units, 6000000002 and 6000000003 |
| Post goods issue | Material document 4900000004 |
| Put it on a truck | Shipment 1458, completed |
| Invoice it | Invoice 90040440 for $7,401.00, posted to accounting |
The moment SAP said no. When the assistant packed the delivery, SAP rejected the first handling-unit number because it was outside the allowed number range. The assistant read SAP's message, corrected the input and packed the two pumps on two pallets, since together they exceeded one pallet's weight limit. Nothing was half-posted.
That step is the difference between a demo and a tool. SAP's own rules did the checking, and the assistant treated the error the way an experienced user would.
The video below shows another session from the same system: a sales order and its delivery, created and then checked in SAP GUI.
How it works
The assistant never touches SAP directly. Every request travels one path:
- The user signs in with their company account through single sign-on.
- The AI assistant, any MCP-capable assistant the company already licenses, receives the request.
- CGR MCP Server, running in the customer's cloud or hosted by CGR, turns it into a call.
- CGR SAP Connector, a native ABAP add-on inside SAP, checks the call and runs it.
- SAP answers from its own tables, reports, BAPIs and function modules.
Nothing is built per request. An administrator approves an SAP object once, and the assistant can use it.
What keeps it inside the rules
The assistant can do only what the person asking is already allowed to do in SAP.
- Named users. Each person maps to one SAP user. Every call runs under that user's own SAP authorizations, never a shared account.
- Two gates on every call. IT keeps a whitelist of approved objects per role. A call must be on the whitelist and inside the user's SAP authorizations.
- Read and write apart. A role can be read-only. Writes need an explicit commit.
- Check, post, verify. The assistant runs a test where SAP offers one, posts on commit, then reads the document back.
- Full audit. Every call is logged in SAP with the user, the object, the time, the request and the response.
A user who cannot see a cost center in SAP cannot see it through the assistant either. For the full list of controls, see the security page.
What it does not do
It does not drive SAP screens. The assistant works through tables, reports, BAPIs and function modules. There is no batch input and no screen processing.
- Custom transactions with logic only in the screens are not reachable as they are. Wrap the logic in a function module, which does not need to be RFC-enabled, and the assistant can use it.
- High-volume batch processing stays deterministic. System-to-system integration uses the same add-on as plain REST APIs, with no AI involved.
- SAP GUI does not go away. Administrators still maintain the whitelist and read the log there. Business users no longer need it for everyday work.
Who it helps besides end users
Functional consultants and developers get a faster working loop. Ask the assistant to run a process and watch where SAP stops: a customer not extended to a sales area, a missing number range, a plant not maintained. Fix it in SAP GUI as always, then ask again. No transaction to re-run and no test script to walk through.
ABAP developers get a short route for custom processes. One simple function module covers a non-standard process, and the assistant knows how to use it once it is whitelisted.
What it needs on the SAP side
| Needed | Not needed |
|---|---|
| SAP ECC 6 or S/4HANA, on-premise, private cloud or RISE | SAP BTP |
| CGR SAP Connector, installed through SAINT | Integration Suite or other middleware |
| A whitelist of approved objects per role | OData services built per object |
| An MCP-capable AI assistant | RFC enablement or wrappers for existing function modules |
How to see it on your own SAP
Start with a 30-minute live demo on a real SAP ECC 6 system: an assistant answers a question, creates a document, recovers from an SAP error and is refused a request it is not allowed to make.
The next step is a four-week pilot in your own system: 5 to 10 named users, read-only, on the questions they already ask SAP every week. The pilot costs $8,000 fixed, credited in full against the licence.
Read how the pilot works.