Loading ToolBench
MCP server for SQL Server database operations with tools for querying, stored procedures, schema discovery, and data management
This MCP server provides 19 database tools with inconsistent quality. Naming conventions are generally good (verb_noun pattern), but critical issues emerge: (1) Many tool descriptions are vague or generic, e.g., 'Discover all tables, views, functions, and procedures' lacks depth on WHEN to call it or what the agent should do next. (2) Input parameter descriptions are often absent or minimal. The ExecuteQueryTool and ExecuteStoredProcedureTool accept string parameters with minimal guidance on format, constraints, or expected values. (3) Output schemas are not documented, tools return strings or text without structured field definitions, forcing LLMs to parse unstructured output. (4) Error handling is present but minimal; code shows try/catch blocks that convert exceptions to 'SqlErrorResult', but there's no evidence of actionable error messages or recovery guidance. (5) Security concerns: execute_query and run_script accept arbitrary SQL, with no mention of permission checks or input sanitization in the visible code. (6) Some tools like 'query_streamer' and 'paginated_query' handle large results, but pagination guidance is sparse. Overall, this is a functional but below-median community MCP server; it solves a real domain problem but lacks the polish and agent-centric design of production tools.
List open cursors and provide cursor usage guidance.
Discover all tables, views, functions, and procedures in the current database.
Execute a SQL query on the connected SQL Server database.
Execute a SQL query in the specified database (requires server mode).
Execute a stored procedure on the connected SQL Server database. Parameters should be provided as a JSON object with parameter names as keys. Both '@ParameterName' and 'ParameterName' formats are accepted. Examples: - Simple parameters: {"CustomerID": 123, "OrderDate": "2024-01-01"} - With @ prefix: {"@CustomerID": 123, "@OrderDate": "2024-01-01"} - Mixed types: {"ID": 123, "Name": "Test", "IsActive": true, "Price": 99.99} - Null values: {"CustomerID": 123, "Notes": null} The tool will automatically convert JSON values to the appropriate SQL types based on the stored procedure's parameter definitions. Use 'get_stored_procedure_parameters' tool first to see what parameters are expected.
Output schemas not documented. Most tools return plain strings (e.g., DiscoverTool returns StringBuilder text). LLMs cannot parse or chain results because field names and types are invisible. No structured output schema provided in tool registration.
Parameter descriptions missing or minimal. ExecuteQueryTool accepts 'query: string' with only description 'The SQL query to execute', no guidance on format, syntax validation, or what happens on error. ExecuteStoredProcedureTool 'parameters' param accepts 'string' with vague description; users cannot know if they should pass '{"key": value}' or other formats without deep reading.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Export a table or query result to CSV.
Get details for a scalar or table-valued function.
Get details for indexes on a table.
Get the definition of a stored procedure in the connected SQL Server database.
Get parameter information for a stored procedure including names, types, and whether they are required. This tool helps you understand what parameters a stored procedure expects before calling it. It supports two output formats: 1. Table format (default): Shows a formatted table with parameter details and example usage 2. JSON format: Returns JSON Schema compatible with the stored procedure parameters Examples: - get_stored_procedure_parameters("sp_GetCustomerOrders") - get_stored_procedure_parameters("dbo.sp_UpdateCustomer", "table") - get_stored_procedure_parameters("sp_ProcessPayment", "json") Table format shows parameter name, SQL data type, whether it's required or optional, direction (INPUT/OUTPUT), and default values. JSON format provides JSON Schema with SQL-specific extensions for parameter validation and documentation. Note: This tool works within the current database context. For cross-database queries, use the server mode.
Get the schema of a table from the connected SQL Server database.
Get details for a view, including columns and definition.
Import data from CSV into a table.
List all stored procedures in the connected SQL Server database.
List all tables in the connected SQL Server database.
Execute a paginated SQL query.
Stream large query results in batches.
Execute a multi-statement SQL script with error reporting and transaction support.
Get SQL Server capabilities
Generic tool descriptions lack actionable context. 'Discover all tables, views, functions, and procedures' does not explain WHEN to call this tool vs others, what format the output is in, or what the LLM should do with the results. Baseline for A+ tools is 50 - 200 chars, descriptive and LLM-optimized; these descriptions are often 30 - 60 chars and vague.
No error recovery guidance. Error handling code (e.g., in ExecuteQueryTool) catches exceptions and returns ToSqlErrorResult(), but visible code does not show constructive error messages. Missing: 'User not found. Try search_users() first.' guidance. Pattern requires errors to tell the LLM what to do next.
No permission gates or input sanitization visible. execute_query and run_script accept arbitrary SQL without documented permission checks or SQL injection defense. A malicious agent could DROP TABLE or DELETE FROM. Rubric requires permission checks and audit trails for destructive tools.
No pagination guidance in list tools. list_tables and list_stored_procedures accept no limit or offset. If a database has thousands of tables, the response could exhaust the context window. Rubric requires pagination support and result limits stated in descriptions.
Inconsistent parameter type naming. execute_stored_procedure uses 'parameters: string' (JSON object as string), while get_stored_procedure_parameters uses 'format: string' with implicit enum ('table'|'json'). No enum constraint visible in schema. LLMs cannot discover valid values; they guess.