Loading ToolBench
MCP server providing SQL-based tools to interact with MongoDB and other JDBC-accessible data sources through standardized database operations (get tables, get columns, run queries)
This MongoDB MCP server has VISIBLE tool definitions with proper schemas and descriptions, but falls short of production quality in several critical areas. All 3 tools have descriptions (10 - 100+ chars), input schemas with types, and parameter descriptions. However, descriptions lack clarity on WHY and WHEN to use each tool, parameters could be more granular, and output schemas are not documented. Error handling is minimal (raw exceptions). The naming is adequate (verb_noun) but generic. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Overall composition is sound, three complementary discovery/query tools with clear separation of concerns.
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. Tools return CSV-formatted text in a TextContent object, but LLMs cannot infer the structure, column names, or data types returned. This forces LLMs to parse unstructured output, increasing error rate and token waste.
Minimal error handling. Tools throw RuntimeException with message 'ERROR: ' + ex.getMessage(). No recovery guidance, no error classification, no actionable next steps for the LLM. A connection failure or malformed SQL just bubbles up as a raw error.
Tool descriptions lack depth. '{prefix}_run_query' description is only 28 characters ('Execute a SQL SELECT statement.'). Missing: when to use vs. get_tables/get_columns, supported SQL dialects, result format, performance limits.
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 | 38 | - | v1 |
No tool annotations. All three tools are READ_ONLY, but MCP annotations (readOnlyHint, idempotentHint) are absent from the tool registration. This prevents clients from understanding tool safety properties without reading descriptions.
Missing parameter constraints. 'sql' parameter in {prefix}_run_query has no minLength, pattern, or enum. 'catalog', 'schema', 'table' are optional strings with no description of format expectations (e.g., quoted identifiers, case sensitivity, max length).
Naming lacks specificity. Tool names (get_tables, get_columns, run_query) are generic. LLMs cannot distinguish intent from the name alone. Consider: list_tables, describe_table_schema, execute_select_query. 'get_tables' could mean fetch one or many; 'list_tables' is unambiguous.
CSV output format is unstructured from the LLM perspective. Descriptions say output is 'CSV format, with the first line containing column headers', but the actual McpSchema.Content is a single TextContent object. LLMs cannot reliably parse CSV, they risk misaligning columns or rows, especially with quoted values or commas in data.
No pagination or result limits documented. {prefix}_get_tables and {prefix}_get_columns could return hundreds or thousands of rows. No mention of limits, pagination, or how to handle large result sets. This risks context-window exhaustion.