Loading ToolBench
MCP server for SAP Cloud Integration providing access to integration packages, flows, mappings, script collections, and runtime artifacts
The CPI MCP Server provides 12 READ_ONLY tools for querying SAP Cloud Integration artifacts. While the tools are well-named and follow a consistent verb_noun pattern (get_*, search_*), they suffer from significant schema and parameter documentation gaps. All tools have descriptions (meeting the basic requirement), but the vast majority lack proper JSON Schema definitions with typed and described parameters. The server uses the go-sdk's mcp.AddTool() mechanism, but actual schema registration is not visible in the provided code, only tool names and descriptions are shown. This prevents verification of input parameter schemas, which are critical for LLM reasoning. Output schemas (MessageMappingsOutput, etc.) are defined but not integrated into the tool registration visible in the source. The tools are read-only and safe, but lack the level of parameter constraint documentation, error recovery guidance, and output metadata that production-grade tools require.
Get all integration flows
Get all integration packages
Get all integration runtime artifacts
Get all message mappings
Get all script collections
Get all value mappings
Search integration flows by ID, version, name, sender or receiver
Input schemas not visible in tool registration. The code shows mcp.AddTool(server, searchIntegrationPackagesTool(), searchIntegrationPackagesHandler) but getIntegrationPackagesTool() returns only &mcp.Tool{Name:..., Description:...} with no InputSchema field. This means input parameter validation, type constraints, and LLM parameter selection cannot be verified.
Search tools define InputSchema via Go struct tags (e.g., MessageMappingsSearchInput with jsonschema annotations), but these are not wired into the mcp.Tool object in the tool registration code. The schema exists in the handler function signature but is not exposed to the client. This prevents LLMs from knowing which parameters are required, their types, or their descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Search integration packages by ID, version or name
Search integration runtime artifacts by ID, version, name, type or status
Search message mappings by ID, version or name
Search script collections by ID, version or name
Search value mappings by ID, version or name
All 'get_*' tool descriptions are generic and under 20 characters ('Get all X'), failing the baseline of 34 - 392 characters for tool descriptions. These descriptions provide no context on when to use get_integration_packages vs search_integration_packages, what the results contain, or pagination behavior.
No documentation of pagination, result limits, or what fields are returned. The code shows MessageMappingsOutput{Results: []MessageMapping} but does not specify how many results to expect, whether large result sets are truncated, or what happens if there are 10,000+ artifacts. Without pagination guidance, agents risk requesting all artifacts and overflowing context.
Search tools accept optional string parameters (id, version, name, sender, receiver) with no documented constraints or enums. LLMs do not know if these are regex patterns, exact matches, case-sensitive, or substring searches. The description 'Search by ID, version or name' does not clarify the matching behavior.
No error handling guidance. The handler functions return error but do not document what errors are possible (e.g., network failure, unauthorized, malformed response) or what the LLM should do next. Per the rubric, errors must tell the agent what to do: 'If authentication fails, check credentials. If rate-limited, retry after 5 minutes.'
Output schema not documented in tool definitions. The MessageMappingsOutput and similar types are defined as Go structs but are not declared in the mcp.Tool.OutputSchema field (which is not visible in the tool registration). LLMs cannot see the structure of results without calling the tool and examining a sample response.