Loading ToolBench
MCP server for querying Epicor Kinetic ERP system via JDBC connection, providing tools to list tables, columns, and execute SQL queries
Three tools with mixed quality. Tool naming follows verb_noun convention (get_*, run_*), which is positive. Descriptions are present and moderately detailed (100-200 chars), explaining purpose and output format. However, parameter descriptions are minimal or absent for several inputs, and output schemas are not documented. The tools accept optional parameters (catalog, schema) but lack validation guidance. Error handling is minimal, tools throw RuntimeException without actionable recovery hints. No evidence of idempotency markers, rate limiting, or security annotations.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `epicor_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 `epicor_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.
epicor_run_query description lacks detail about output format, constraints, and when to use it vs. discovery tools. Description is only ~50 chars, below the 10 - 1024 recommended range for clarity.
No output schemas documented for any tool. LLMs cannot anticipate the structure of returned CSV data (column headers, field types, pagination). This forces the agent to inspect responses and guess downstream tool requirements.
Parameter descriptions are vague or missing. 'catalog' and 'schema' are described as 'The catalog name' and 'The schema name' with no guidance on format, whether they are required, or how they interact. The 'table' parameter in get_columns lacks description of valid table names or format.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
epicor_run_query parameter 'sql' lacks detailed constraints. No mention of supported SQL clauses beyond a brief list ('FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET'). No guidance on quoting identifiers, max result size, or timeout behavior.
Error handling is non-actionable. Tools catch exceptions and rethrow RuntimeException with only the underlying message. No error classification (retryable vs. fatal), no guidance on next steps, no invalid input examples for self-correction.
No pagination support in tool designs. If a table contains thousands of rows or columns, the entire result is returned as CSV, risking context window exhaustion. Tools should accept limit and offset parameters and document result caps.
No input validation. Tools do not validate SQL syntax, protect against injection, or check parameter bounds. LLMs can pass arbitrary SQL; the tool silently fails or succeeds without guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While the tools appear read-only, there is no explicit declaration. This leaves the agent to infer safety from descriptions.