sap-integration-suite-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | MCP HTTP server host. | 127.0.0.1 |
| MCP_PORT | No | MCP HTTP server port. | 3000 |
| LOG_LEVEL | No | debug, info, warn, error or silent; default info. | info |
| SAP_BASE_URL | Yes | Tenant origin or /api/v1 root; required HTTPS. | |
| SAP_AUTH_MODE | No | SAP authentication mode; oauth2 only. | oauth2 |
| SAP_CLIENT_ID | Yes | Required technical-client credential (client ID). | |
| SAP_TOKEN_URL | Yes | OAuth token endpoint; required HTTPS. | |
| MCP_HTTP_TOKEN | No | Independent MCP bearer token; at least 32 characters for remote binds. | |
| MCP_ALLOWED_HOSTS | No | Comma-separated exact Host authorities; default localhost:3000,127.0.0.1:3000. | localhost:3000,127.0.0.1:3000 |
| SAP_CLIENT_SECRET | Yes | Required technical-client credential (client secret). | |
| MCP_ALLOWED_ORIGINS | No | Comma-separated exact Origin URLs; default rejects browser Origins. | |
| SAP_REQUEST_TIMEOUT_MS | No | Per-request timeout, default 30000, range 100-120000. | 30000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_failed_messagesC | Retrieve failed message metadata; package filtering is unsupported. |
| search_messagesC | Search normalized message metadata (maximum 500 results). |
| get_message_detailsB | Retrieve message processing log metadata without business payloads. |
| get_error_detailsC | Retrieve sanitized error information and deterministic indicators. |
| get_iflow_statusC | Retrieve runtime artifact status, or an explicit unavailable result. |
| get_recent_failuresC | Retrieve failures within the last N minutes. |
| summarize_integration_healthC | Calculate statistics from up to 500 messages; defaults to the past 24 hours. Check truncation. |
| analyze_failureA | Gather sanitized diagnostic evidence and deterministic investigation areas; no AI root-cause claim. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
There is noticeable overlap between get_failed_messages and get_recent_failures, as both retrieve failure data, and get_message_details versus get_error_details could cause some confusion. Descriptions help distinguish them, but the boundaries are not entirely crisp.
All tool names follow a consistent snake_case verb_noun pattern (get_failed_messages, search_messages, summarize_integration_health). No mixed conventions or vague verbs are present.
Eight tools is well-scoped for a diagnostic monitoring server, and each tool appears to earn its place by covering a distinct aspect of message/error/health inspection. The count avoids both thinness and bloat.
The surface covers core read-only diagnostic needs: searching messages, inspecting failures, retrieving details and errors, checking iflow status, summarizing health, and analyzing failures. Minor gaps exist, such as unsupported package filtering in get_failed_messages and no direct payload retrieval, but these are largely intentional or workaroundable.