Loading ToolBench
MCP server for BigCommerce API integration that provides tools for querying database tables, columns, and executing SQL queries
The server provides 3 data-discovery and query tools with moderate quality. Tool naming follows verb-noun convention (get_tables, get_columns, run_query) and is clear and actionable. Descriptions are present and reasonably detailed (150-200 chars), with helpful context about CSV output format and parameter usage. However, several critical gaps reduce overall quality: (1) parameter descriptions are minimal or absent in some cases, (2) output schemas are not formally documented, only CSV format is mentioned, (3) error handling lacks recovery guidance, (4) no input validation rules are visible. The server is functional but would not pass a code review for production use without significant improvements to documentation and error handling.
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 schemas not documented. Tools describe results only as 'CSV format with headers' but do not specify which fields/columns will be returned or their types. LLMs cannot plan downstream operations without knowing the response structure.
Parameter descriptions are minimal. 'catalog' is described as 'The catalog name' and 'schema' as 'The schema name', but do not explain: (a) when to use them (optional vs required), (b) format constraints, (c) what happens if omitted. The description for 'sql' in run_query mentions valid SQL clauses but does not specify timeout limits, result limits, or error handling.
No error handling guidance. Code throws RuntimeException('ERROR: ' + ex.getMessage()) without categorizing errors as retryable, user-fixable, or fatal. LLMs receive raw error messages with no instruction on next steps (e.g., 'Table not found. Try get_tables() first.').
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 | 32 | - | v1 |
No input validation rules documented. run_query accepts arbitrary SQL but does not document restrictions (e.g., 'SELECT only', 'no INSERT/UPDATE/DELETE', max result rows). Constraints must be stated in parameter descriptions so LLMs understand what inputs are safe.
No pagination documented. Tools return CSV results but do not document: (a) row count limits, (b) pagination support (LIMIT/OFFSET), (c) whether large result sets are truncated. Without pagination guidance, agents may request huge result sets that exhaust context or API resources.
Parameter 'table' in get_columns is required, but 'catalog' and 'schema' are optional. No explanation of why table is required but catalog/schema are optional, or what the API defaults to when catalog/schema are omitted. Agents need to know this dependency to construct correct calls.