Loading ToolBench
MCP server for deploying SAP ABAP accelerator functionality with enterprise features including principal propagation authentication, multi-tenancy, usage tracking, and certificate-based authentication
This SAP ABAP Accelerator server exhibits significant definition quality issues. While 17 tools are declared, many share overlapping responsibilities (duplicate tool definitions for aws_abap_cb_connection_status, aws_abap_cb_get_objects, aws_abap_cb_get_source), indicating poor composition and confusing tool design. Naming conventions are reasonably consistent (verb_noun pattern with 'aws_abap_cb_' or action prefix), but descriptions are often generic and lack LLM-optimization. Parameter descriptions are present but vary in quality, many lack explicit type constraints, enums, or guidance on dependencies. Most critically, output schemas are not documented in the provided source; we cannot verify what fields tools return or how they chain together. Error handling details are absent from the tool definitions. Security considerations around credential handling are partially addressed via environment variables and keychain managers, but no evidence of permission gates or audit trails in the tool definitions themselves.
Universal authentication method supporting all auth types
Activate one or more ABAP objects after syntax check. Supports both single object and batch activation.
Activate multiple ABAP objects in a single batch request to resolve circular dependencies. Each object should have 'name' and 'type' fields. This uses SAP's batch activation endpoint which can handle circular dependencies between objects.
Check syntax of ABAP object source code
Check SAP connection status
Check SAP connection status
Duplicate tool definitions: aws_abap_cb_connection_status, aws_abap_cb_get_objects, and aws_abap_cb_get_source are each defined twice with different input schemas. This violates single-responsibility principle and creates ambiguity for LLM tool selection.
Output schemas not documented. No tool definition includes return type documentation, field descriptions, or example response structures. LLMs cannot infer what fields to expect or how to chain tools without this critical information.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Create new ABAP object in SAP system
Get ABAP objects from SAP system
Get ABAP objects from SAP system
Get source code of ABAP object
Get source code of ABAP object
Run ATC (ABAP Test Cockpit) check on object
Update source code of an existing ABAP object. Locks the object, writes source, then unlocks.
Get information about keychain storage capabilities
Get list of supported authentication types
Initiate SAML/SSO authentication flow
List active authentication sessions for current user
Parameter 'credentials' in authenticate_user is typed as 'object' with no schema constraints or nested field documentation. This forces LLMs to guess at required fields, auth_type, and format. Should be strongly typed with nested schema or separate parameters per auth_type.
Missing error handling guidance in all tool definitions. No descriptions indicate what errors are retryable, what user-actionable corrections exist, or what the tool does on failure (e.g., partial activation in batch operations).
Implicit dependencies undocumented. aws_abap_cb_update_source requires an object to be locked before use, aws_abap_cb_activate_object depends on successful syntax check, and batch activation hints at circular dependency resolution. LLMs receive no guidance on prerequisite calls or failure modes.
Optional parameters with unclear defaults. sap_system_id, package_name, transport_request, and others are marked optional with no clear guidance on fallback behavior (environment variable, header, or error). 'If not provided, uses x-sap-system-id header or DEFAULT_SAP_SYSTEM_ID env var' should be in the description, not inferred from code.
No input validation constraints. auth_type in authenticate_user accepts 'basic', 'playwright', 'browser', 'reentrance_ticket', 'ticket' but no enum is enforced. object_type in multiple tools accepts 'CLAS', 'INTF', 'PROG', 'DDLS', 'BDEF', 'SRVB', 'BIMPL' without enum constraints. Binding_type and visibility likewise lack enums despite fixed valid sets.
Composition violation: aws_abap_cb_update_source description states it 'Locks the object, writes source, then unlocks', a multi-step atomic operation exposed as one tool. If locking fails, the tool partially succeeds, leaving the object locked and confusing the agent. Should either guarantee atomicity or expose lock/unlock as separate tools.
Overlapping tool intent between aws_abap_cb_activate_object and aws_abap_cb_activate_objects_batch. Both activate objects, but the distinction (single vs batch) is not clear from naming alone. Tool names should unambiguously distinguish intent, e.g., 'activate_single_object' and 'activate_multiple_objects_batch'.
Unclear parameter mutuality in aws_abap_cb_activate_object. It accepts both 'object_name' + 'object_type' (single) AND 'objects' (array) simultaneously. The description should state which combination is valid and what happens if both are provided.
No idempotency guarantees documented. If an agent retries aws_abap_cb_create_object with the same name and package, does it fail with 'object exists', create a duplicate, or return the existing object? Without clear idempotency semantics, agents cannot safely retry on transient failures.