Loading ToolBench
MCP server providing SQL query execution, table enumeration, and column metadata discovery for SAP Ariba data sources via JDBC
This server exposes 3 data discovery and query tools for SAP Ariba. Tool definitions are present with schemas and basic descriptions, but there are significant gaps in parameter descriptions, output schema documentation, error handling guidance, and composition patterns. Naming is acceptable (verb_noun pattern), but descriptions lack detail about when to use each tool, what outputs contain, and how they chain together. Parameters are defined with types but lack format constraints, ranges, or detailed guidance. The CSV output format is mentioned but no structured schema is provided for interpreting results. Error handling is minimal, failures throw RuntimeException with a message, providing no recovery guidance. No tool annotations (readOnlyHint, etc.) are present despite these being read-only operations. STDIO transport is a hard cap at 50.
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.
Output schema not documented for any tool. All three tools return CSV-formatted text, but the structure, field names, and interpretation are not specified. LLMs cannot plan downstream operations or extract data reliably from unstructured text output.
Parameter descriptions are minimal or missing context. 'catalog', 'schema', and 'table' parameters lack guidance on format, examples, or when they are required vs optional. The 'sql' parameter in run_query mentions SQL dialect and valid clauses but does not specify identifier quoting, character restrictions, or maximum query length.
Tool descriptions do not explain when to use each tool or dependencies. For example, get_columns description states 'Use get_tables to get a list' but does not explain that catalog and schema are optional filters. run_query description does not mention pagination limits, expected output structure, or how to compose multi-table queries.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error handling provides no recovery guidance. All tools throw RuntimeException('ERROR: ' + message) on failure. LLMs receive no actionable direction: is this retryable? Should they call search_users()? Is it a malformed query? A timeout?
No tool annotations despite read-only semantics. Tools should declare readOnlyHint: true to signal to agents that they are safe to call without side effects. This aids planning and error recovery strategies.
Parameters accept free-form strings with no enum constraints. 'catalog' and 'schema' are optional but unconstrained, LLMs may pass arbitrary values causing discovery overhead or errors. If known catalogs or schemas exist, they should be enumerated.
run_query lacks pagination parameters and result limiting. No mention of max row limits, pagination support, or expected result cardinality. Agents cannot safely execute queries that might return thousands of rows, risking context window exhaustion.
Tool descriptions are below baseline length (194 chars avg). get_tables: ~150 chars, get_columns: ~180 chars, run_query: ~30 chars. The run_query description is critically short and lacks context for LLM selection.