Loading ToolBench
MS SQL MCP Server for database schema introspection and query execution
This MCP server has critical definition quality issues. Both tools have minimal or missing descriptions, no parameter validation metadata, and empty input schemas. The 'run_your_query' tool is particularly dangerous, it accepts arbitrary SQL strings with no validation, escaping, or injection protection. Neither tool provides structured guidance for LLM behavior. The 'get_schema' tool has a vague one-sentence description (15 chars, below the 20-char floor), and 'run_your_query' lacks parameter documentation entirely. Output schemas are not documented, LLMs cannot plan multi-step queries without knowing what fields to expect. This server exemplifies poor agent-tool design: high-risk operations (arbitrary SQL execution) exposed with minimal guardrails.
Returns database schema structure.
Execute an AI generated query.
CRITICAL: 'run_your_query' tool accepts arbitrary SQL with zero input validation, SQL injection protection, or parameter escaping. The parameter lacks any description, format constraints, or examples. This exposes the database to prompt injection attacks, an LLM can be tricked into passing 'DROP TABLE users' or exfiltrating sensitive data.
Tool name 'run_your_query' violates verb_noun convention and is vague. 'execute_sql_query' or 'query_database' would be clearer. The name does not convey risk (WRITE operation) or that this is for AI-generated queries only.
Description for 'run_your_query' is missing entirely. Parameter 'query' has no description explaining what SQL dialect is accepted, what operations are allowed/forbidden, expected result format, or limitations. Baseline requires 10-1024 chars; this is 0.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Description for 'get_schema' is 31 chars ('Returns database schema structure.'), under the 10-1024 baseline but borderline. It lacks context on when to call this, what fields are returned, or whether it includes permissions/constraints. No guidance for LLM on what to do with the output.
Input schema for 'run_your_query' is empty: {} with no properties. The 'query' parameter is defined in the function signature but NOT in the JSON Schema. This tool cannot be called correctly via standard MCP protocol.
Output schemas are not documented. 'get_schema' returns a dict with 'database' and 'schema' keys, but the nested structure is not declared. 'run_your_query' returns a list of dicts, but the keys and types are unknown to the LLM. Without documented output schemas, LLMs cannot plan multi-step operations or extract required fields for chaining.
No error handling guidance. If a query times out, returns no rows, or fails due to permissions, the user/LLM receives an exception with no recovery path. No indication whether errors are retryable or what the LLM should do next.
Credentials (DB_DRIVER, DB_SERVER, DB_DATABASE, DB_UID, DB_PWD) are correctly injected via environment variables, not tool parameters. However, there is no audit trail, permission gating, or rate limiting to track who ran what query. An agent can execute unlimited queries without logs.
No idempotency safeguards. If an LLM retries a write query (INSERT, UPDATE, DELETE) due to a transient error, duplicate records or unintended side effects occur. No confirmation step, dry-run, or transaction rollback offered.