Loading ToolBench
An MCP server that integrates PostgreSQL database access with Ollama for AI-powered SQL generation, exposing database tables as resources and providing SQL query execution as tools.
This MCP server exposes only one tool (sql://query) with critical quality gaps. The tool lacks proper input schema documentation, has minimal description, and critically exposes SQL injection vulnerabilities. The naming convention is non-standard (uses URI-style 'sql://query' instead of verb_noun pattern like 'execute_query'). The implementation directly accepts a raw SQL query string with no validation, sanitization, or parameterization. The server is fundamentally unsafe for agent use and violates core MCP patterns for tool definition, error handling, and security.
Execute a SQL query against the PostgreSQL database and return results as a list of dictionaries
Tool name violates verb_noun convention. 'sql://query' uses URI syntax instead of action verbs (execute_query, run_sql_query, query_database). LLMs cannot infer intent from 'sql://' prefix, it reads more like a resource URI than a tool action.
CRITICAL SECURITY: Tool accepts raw SQL strings with no parameterization, validation, or injection protection. Description states 'Execute a SQL query' but does not warn about SQL injection risk or document required precautions. An agent can be tricked into passing malicious SQL (e.g. 'DROP TABLE users;--'). This violates pattern:tool-gateway and pattern:secret-injection (credentials in query strings leak into logs).
Input schema is minimal. Only one parameter 'query' (string, no constraints). Missing: format constraints (length limits), SQL syntax validation hints, examples of safe vs unsafe queries, or guidance on parameterized queries. The schema should document what SQL is allowed (SELECT only? DML? DDL?) and enforce it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Description is generic (54 chars): 'Execute a SQL query against the PostgreSQL database and return results as a list of dictionaries'. Missing: WHEN to use this tool, WHAT queries are safe, WHETHER the tool supports writes or only reads, HOW to handle errors, WHAT 'list of dictionaries' format means. LLMs cannot determine correct usage from this alone.
No output schema documented. Returns 'list of dictionaries' but does not specify field names, types, or structure. The tool should document: 'Returns array of {column_name: value, ...} objects' with example. Without output schema, agents cannot plan downstream calls or extract needed data.
No error handling or recovery guidance. If query fails (syntax error, permission denied, timeout), the server likely returns a raw exception or HTTP 500. No guidance on: retryability, user-fixable vs fatal errors, invalid value reporting, or next steps for the agent. Violates pattern:recovery-guide.
No permission checks or scope declarations. The tool does not verify that the calling agent/user has authority to execute queries. No audit trail visible (who called what query when). Missing pattern:permission-gate and pattern:audit-trail.
Potential credential leakage. If a user passes a database URL or connection string as part of the query, it would be logged in tool parameters and MCP traces. The server should never accept credentials; all DB auth should be server-side injection via environment variables.