Loading ToolBench
MCP server providing tools to interact with Microsoft Exchange data sources through SQL-based queries, table discovery, and column inspection
This server defines 3 tools for querying Microsoft Exchange via SQL. Tool names follow verb_noun convention (get_tables, get_columns, run_query), which is good. However, descriptions lack depth and parameter definitions are incomplete. Schemas are present but minimal. The descriptions are functional but generic, they explain WHAT the tools do (retrieve tables/columns, execute SQL) but not WHEN to use them or what distinguishes one from another. Parameter descriptions are terse (e.g., 'The catalog name' with no guidance on format, optionality, or when it's needed). No output schema is documented anywhere. Error handling is minimal, exceptions are caught and thrown as generic RuntimeExceptions with only the message text. There is no guidance for recovery (e.g., 'If catalog not found, try omitting the catalog parameter'). The tools are read-only and simple, which is good for safety, but the lack of result limits, pagination support, and output field documentation means agents will struggle to use these tools effectively on large datasets.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `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 `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 return CSV-formatted text but the LLM is not told which columns to expect, their types, or ordering. This forces the LLM to infer schema from unstructured output.
No result limits or pagination support. run_query accepts arbitrary SELECT statements with no LIMIT enforcement. Large result sets will blow context windows and waste tokens.
Error handling provides no recovery guidance. Exceptions are caught and re-thrown as generic RuntimeExceptions with only the message text. The LLM has no idea whether to retry, call a different tool, or ask the user.
Parameter descriptions are terse (1-4 words). 'The catalog name', 'The schema name', 'The table name', 'The SELECT statement to execute' lack guidance on format, constraints, or when each is required vs. optional.
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 | 35 | - | v1 |
Tool descriptions lack context on when to call each tool. All three are discovery/query tools but their distinct use cases (list tables vs. list columns vs. execute custom queries) are not explained.