Loading ToolBench
SQL Server DBA monitoring MCP server with full T-SQL access, supporting multi-instance queries, performance analysis, and blocking chain detection
Five tools with clear verb-noun naming and comprehensive descriptions (avg 180 chars). All tools have input schemas with type definitions and parameter descriptions. Tool names follow action-verb convention (list_, fan_out_, execute_, get_). Descriptions explain WHAT, WHEN, and prerequisites. However, output schemas are not formally documented, responses are inferred from code (toJson wrapping). Error handling returns actionable messages but lacks categorization (retryable vs fatal). No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Parameter descriptions are strong but some lack explicit constraints (e.g., query validation is runtime-only, not schema-declared). Truncation handling is present but not documented in output schema.
Execute a read-only T-SQL SELECT statement. Use this for ad-hoc DMV analysis, custom JOINs across multiple DMVs, CTEs, and CROSS APPLY queries that pre-built tools don't cover. Connects to the master database by default. Only SELECT/WITH/DECLARE statements are allowed.
Run the same read-only T-SQL SELECT statement across all registered SQL Server instances simultaneously (or a specified subset) and return results keyed by instance name. Use this when you want to compare the same metric — wait stats, top queries, blocking — across the whole fleet at once. Failures on individual instances are returned as errors without cancelling the others.
Get all active SQL Server sessions with current request details, CPU, blocking status, and current SQL text. Best starting point for performance investigations. Uses CROSS APPLY dm_exec_sql_text to fetch the actual query being run.
Show all current blocking chains — which sessions are blocked and which session is causing the blockage. Includes the SQL text of both the blocked and blocking session, wait time, and lock details. Returns a message if there is no blocking.
List all configured SQL Server instances available for querying. Call this first when the user does not specify which instance they want, or to verify what instances are registered.
Output schemas not formally documented. Responses are JSON-wrapped text; no structured schema declaration for fields returned (rows, truncated, error, instance, etc.). LLMs cannot plan downstream tool calls without knowing response structure.
No tool annotations despite all tools being read-only. Missing readOnlyHint metadata would help agents understand safety and retry semantics. Spec 2026-07-28 supports tool annotations.
Query validation is runtime-only (validateQuery in safety.ts). Schema should declare allowed patterns (SELECT/WITH/DECLARE only) as a constraint, not just in description. Prevents LLM from passing invalid T-SQL.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | <=2025-11-25 | v2 |
Truncation behavior (200-500 row limit) is not declared in schema. Clients cannot know results are capped without reading code. Should document max_rows in output schema and include truncated flag in structured response.
Error responses lack categorization. Errors return plain text but do not indicate if they are retryable (connection timeout), user-fixable (invalid instance name), or fatal (malformed SQL). Agents cannot decide next action.