Loading ToolBench
Model Context Protocol server for SAP Ariba Procurement data access via JDBC. Exposes tools to query tables, retrieve column metadata, and execute SQL SELECT statements against SAP Ariba data sources.
This is a data-access MCP server for SAP Ariba with 3 tools focused on table discovery and SQL query execution. Tool definitions are visible and properly registered with schemas and descriptions. However, there are significant gaps in parameter descriptions, output documentation, and error handling guidance that would impede LLM reasoning. All tools follow verb_noun naming (get_tables, get_columns, run_query), which is strong. Descriptions exist but are generic and lack WHEN/WHY context. Schema definitions are present with proper type declarations, but parameter descriptions are minimal and output schemas are completely undocumented. Error handling does not guide recovery, exceptions are wrapped in generic RuntimeException. No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY, which represents a missed opportunity for safety signaling.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `{prefix}_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `{prefix}_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Parameter descriptions are minimal and lack actionable detail. 'The catalog name' and 'The schema name' do not explain when to use them, whether they are optional/required in practice, or how they map to the SAP Ariba data model. A description should guide the LLM: e.g., 'The catalog name (optional; leave blank to use default SAP catalog). Required only if querying cross-system data.' Current descriptions force LLMs to guess.
Output schemas are completely undocumented. Tools return CSV-formatted data (stated in description) but the actual schema structure, column names, data types, example rows, is not documented. LLMs cannot plan downstream operations without knowing what fields to expect. The run_query tool should document: 'Returns a CSV with headers derived from the SELECT statement. First row contains column names; subsequent rows contain data values as strings.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | 0.8.1+ | v1 |
Error handling is non-actionable. All exceptions are caught and rethrown as generic RuntimeException('ERROR: ' + message). This leaves the LLM with no recovery path. For example, if a table name is invalid, the agent does not know whether to retry with a different table name, call get_tables() first, or consult the user. Per the rubric, error responses must tell the LLM what to do next: 'Table not found. Call {prefix}_get_tables to list available tables.' instead of a raw exception.
Tool annotations missing. All three tools are READ_ONLY (stated in the risk field) but this safety hint is not declared in the tool registration. The MCP spec supports readOnlyHint annotations that signal to the agent whether a tool modifies state. Using mcp.tool(..., readOnlyHint=true) would explicitly mark these as safe to retry and safe to call speculatively, improving agent reasoning.
The run_query tool description states valid SQL clauses (FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET) but does not document limits on result size. For LLM safety, tools returning large result sets should cap output (e.g., 'Returns up to 10,000 rows') and document pagination if needed. Without a cap, a rogue SQL SELECT * could dump a massive dataset, exhausting context and wasting tokens.
Parameter 'sql' in run_query lacks format constraints in the description. While the description mentions SQL-92 dialect and quoted identifiers, it should specify: 'Only SELECT statements allowed. No INSERT, UPDATE, DELETE, or DDL. Use backticks or double-quotes for identifiers.' This prevents LLMs from attempting write operations and makes constraints machine-parseable.
No dependency hints in tool descriptions. Tools are designed to be called in sequence (get_tables → get_columns → run_query), but descriptions do not guide the LLM on this order. Adding hints like 'Typically called after {prefix}_get_tables to list available columns' helps the agent build better plans and reduces failed tool calls.