Loading ToolBench
MCP server for SQL Server that provides tools to query metadata, execute read-only queries, run stored procedures, and manage caching
SqlServerMCP has 6 tools with visible schema definitions and descriptions. However, critical issues limit its quality: (1) Tool names lack clear verb-noun structure, 'ExecuteQuery' and 'ExecuteStoredProcedure' are generic action names that don't follow the recommended verb_resource pattern (e.g., 'query_database', 'execute_procedure'). (2) Most parameter descriptions are present but terse (avg ~40 chars), lacking actionable constraints and dependency hints. (3) Output schemas are partially documented via return object structures but lack explicit schema documentation in tool definitions, LLMs cannot predict the structure from descriptions alone. (4) Input schemas for some tools are minimal or empty: GetMetadata and ClearMetadataCache have empty input {}, no parameters documented. (5) Error handling is present but generic, error messages like 'No fue posible obtener metadatos' lack recovery guidance. (6) Security validations exist (QuerySecurity.ValidateReadOnlyQuery) but are not reflected in tool annotations. The server is functional but falls short of production-grade tool design standards.
Limpia la caché de metadatos en el proveedor SQL (solo para SqlServerMetadataProvider).
Ejecuta una consulta SQL de solo lectura y devuelve los resultados con límites de seguridad.
Ejecuta un procedimiento almacenado con parámetros opcionales y devuelve los resultados.
Obtiene las columnas de una tabla o vista de SQL Server.
Obtiene metadatos de SQL Server: tablas, vistas, procedimientos y relaciones.
Obtiene estado simple de la caché (claves y expiración) para depuración.
Tool names lack clear verb_noun structure and specific action indication. 'ExecuteQuery' and 'ExecuteStoredProcedure' are generic, LLMs cannot distinguish from names alone why one is preferred over the other in different contexts.
Empty input schemas for GetMetadata and ClearMetadataCache: both declare Input: {} with no parameters. These tools lack parameter documentation despite accepting optional context via IMetadataProvider injection.
Output schemas not documented in tool definitions. While code returns typed objects (QueryResult, MetadataResult, ColumnsResult), the tool descriptions do not specify what fields the LLM should expect. LLMs cannot plan downstream calls or extract chaining IDs without explicit schema documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Parameter descriptions lack actionable constraints and ranges. E.g., 'maxRows' says '1-10000' but doesn't explain the rationale or what happens if the limit is exceeded. 'timeoutSeconds' defaults to 30 but doesn't explain connection behavior on timeout. LLMs cannot reason about optimal values.
Error messages are not actionable. CreateSafeError returns generic messages like 'No fue posible obtener metadatos' without suggesting recovery steps.
Tool annotations missing. ExecuteStoredProcedure is marked as WRITE risk but lacks readOnlyHint/destructiveHint annotations in schema. GetMetadata and read-only tools lack readOnlyHint. Per current spec (2026-07-28), tool annotations are expected for risk classification.
ExecuteStoredProcedure accepts 'parameters' as untyped Dictionary<string, object>. No validation of parameter types, names, or required vs optional. LLMs cannot infer what parameters a stored procedure accepts without a separate discovery step.
Pagination in ExecuteQuery is documented but output schema doesn't explicitly state pagination format. Code returns PaginationResult with fields like Page, PageSize, TotalAvailable, but LLM has no schema reference to know whether to expect 'pagination.page' or 'page' at the top level.