Loading ToolBench
MCP server and Python client for the SAP ADT REST API — search, read, write, activate and transport ABAP objects
Server has 19 tools with complete schemas and descriptions, but quality is uneven. Naming follows verb_noun convention well (sap_connect, sap_read_source, sap_write_source). Descriptions are present but often lack actionable context, many are 1-2 sentences without explaining WHEN to use the tool or what happens on failure. Parameter descriptions are minimal (e.g., 'Name of the ABAP object' repeated across 6+ tools). No output schemas documented. Error handling exists but responses are JSON blobs without recovery guidance. Security is strong (credentials via keyring, no secrets in params). Composition is good, tools are single-purpose and chainable. Average tool description ~120 chars (below 194-char baseline), and parameter descriptions average ~40 chars (well below 72-char baseline).
Activate (compile) an ABAP object.
Browse the package tree structure.
Check if an ABAP object is locked.
Connect to an SAP system via ADT REST API. Resolution order for each parameter: 1. Explicit argument passed to this tool 2. Saved environment (if system_id is provided) 3. Environment variables (SAP_HOST, SAP_PORT, …) 4. Built-in defaults Password resolution: 1. Explicit password argument 2. SAP_PASSWORD environment variable 3. OS credential manager (if system_id is provided or can be inferred) Use sap_save_password to store credentials securely in the OS credential manager so you never need to pass passwords in plain text.
Create a new ABAP class.
Create a new ABAP interface.
Output schemas not documented. Tools return data but LLMs cannot predict field names, types, or structure. Forces agents to guess or fail on downstream chaining.
Parameter descriptions are minimal and repetitive. 'Name of the ABAP object' appears in 6+ tools without explaining what makes a valid name, length limits, or naming conventions (e.g., must be uppercase, max 30 chars).
Discovery tools (sap_discovery, sap_browse_package) lack context on WHEN to call them. No guidance on whether to call before search, or what structure they reveal.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Create a new ABAP package.
Create a new ABAP program.
Create a new transport request.
List available ADT services on the connected SAP system.
Export DDIC objects (tables, data elements, domains, views) as Markdown.
List transport requests.
Read the source code of an ABAP object.
Release a transport request.
Search for ABAP objects by name, type, or package.
Run syntax check on an ABAP object.
Report what the connected system supports — run this on older releases. Combines the ADT discovery document with a read-only probe of the endpoints the other tools depend on, so you learn up front which features exist on this release instead of hitting 404/406/415 one tool at a time.
Run transport checks on a transport request.
Write source code to an ABAP object.
Error responses are JSON blobs without recovery guidance. sap_connect returns {'error': True, 'message': '...'} but does not categorize errors as retryable, user-fixable, or fatal.
No confirmation or dry-run pattern for destructive operations. sap_write_source, sap_activate, sap_release_transport modify state without a preview or confirmation step.