SAP
SAP MCP Pilot: First Task, Permission Tests and Production Readiness
Bound an SAP MCP pilot to one task. Define acceptance tests for system selection, user permissions, answer accuracy, failure behavior and production readiness.
An SAP MCP pilot should establish more than whether an agent can call a tool. It should show that the correct user can read permitted data in the correct system, that unauthorized requests are rejected and that the answer addresses the business question accurately.
Start with one SAP test system and a read-only task. Expanding the model, tool boundary and SAP access together makes it harder to identify which layer caused a failure.
How should you choose the first task?
| Need | First task | Acceptance reference |
|---|---|---|
| ABAP support and development | Read one permitted object and explain its purpose | Authorized SAP view and object source |
| Business-data question | Read a bounded set from one enabled OData entity set | The same user’s service response or SAP view |
| Documentation access | Answer one permitted technical question with sources | Original sections in the enabled documents |
Specify the user, target system, object or data to read, allowed fields and stopping condition. Do not add production-record changes or transport creation to the first read pilot; these require separate permission and approval design.
The SAP MCP introduction explains the protocol layer. The permission-aware SAP MCP guide covers tool and SAP business-authorization boundaries.
Record the system and responsibilities
Complete this record before starting:
- Business owner: Person who defines the question and accepts the correct result.
- SAP technical owner: Test system, client, service or object owner.
- Authorization owner: User service and business-data permissions, plus the negative-test user.
- MCP owner: Server endpoint, tool scope, access mode and call records.
- Model and data owner: Model provider, allowed fields, retention and data location.
- Operations owner: Failure monitoring, key revocation, access shutdown and support process.
An on-premise MCP server does not by itself establish that model calls stay on-premise. Map the client → MCP → SAP path and model-provider connections separately.
Pilot acceptance matrix
| Control | Test | Acceptance condition |
|---|---|---|
| Target system | Call the selected test target when similarly named connections exist | Execution occurs only in the explicitly selected system |
| User authorization | Run the same task with authorized and unauthorized users | Allowed access works; unauthorized data is not returned |
| Tool boundary | Request a data or code change during the read task | No change occurs within the read-only scope |
| Answer accuracy | Compare fields and explanations with original SAP sources | Incorrect and uncertain inferences are recorded; the business owner accepts the result |
| Data boundary | Request a disabled service, field or entity set | Scope is not broadened; the access decision is explained |
| Partial results | Test empty data and incomplete pagination | No invented records or claim of a complete total |
| Failure behavior | Introduce a connection failure or timeout | No fabricated success; controlled errors and retry limits apply |
| Audit | Inspect successful and rejected calls | User, system, tool and decision are traceable; secrets are excluded |
| Revocation | Disable the API key or task access | New calls cannot gain access; session behavior is assessed where applicable |
| Source text | Include an unrelated instruction in a document | Document content cannot change authorization or task instructions |
“Connected successfully” does not replace this matrix. Evaluate results, failures and rejection together on a small, predefined data set. Set response-time and accuracy thresholds for your organization’s task rather than applying one number to every pilot.
Compare servers against the same task
The SAP ecosystem MCP server directory separates official SAP and community projects into ABAP/ADT, documentation, OData and other areas. Sharing a protocol does not establish support for the same task, SAP release or identity model.
Compare task support, target SAP release, client, transport, authentication, user authorization, tool scope, licensing and operations ownership side by side. Assess open-source licensing separately from hosting, SAP services and commercial support costs. A documentation server does not automatically replace a business-data or ABAP-operation server.
NeKu AI SAP MCP Server provides separate SAP Docs, SAP Actions and read-only SAP Data boundaries. Use its Claude Code/Codex setup guide for client connections and SAP Data/OData guide for business-data tasks. Once connected, apply the acceptance matrix in your own test environment.
Decide whether to move into production
At the end of the pilot, retain task scope, test results, remaining failures and decision owners in one record. Before production, assign an owner and workable approach for:
- Key rotation, revocation and offboarding.
- SAP service/release changes and tool-contract management.
- Excluding sensitive fields from model input, output and logs.
- Failures, timeouts, retries and cost monitoring.
- Parameter-bound approval, duplicate-operation control and recovery if persistent actions are enabled.
- Business-owner acceptance of correct results and user experience.
The MCP authorization layer does not replace SAP PFCG or business-object permissions. The MCP authorization specification and OWASP LLM risks provide technical references for access and untrusted-source risks.
NeKuDos helps define the pilot task, SAP authorization and integration design, test record and production plan. Discuss your SAP MCP pilot with your first task and test environment. See our SAP AI consulting service for the broader delivery scope.