Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The server implements 9 database tools with reasonable naming conventions (all verb-first: query, execute, list_*, describe_*, transaction_*, connection_*) and documented schemas. However, critical gaps exist: (1) Parameter descriptions are minimal or generic ('Optional connection ID to reuse existing connection' appears verbatim in 8 tools with no guidance on format or lifetime); (2) Output schemas are NOT documented anywhere, the source shows only input parameter schemas; (3) Error handling is absent from tool descriptions, no guidance on what errors to expect or how to recover; (4) The 'connection' parameter (present in 8 tools) accepts an object but no schema details are visible for its internal structure (db_type, host, port, database, username, password, schema, jdbc_url are mentioned in descriptions but not formally defined); (5) Connection credential injection violates the secret-injection pattern, credentials appear to flow through tool parameters rather than server-side injection. Tool naming is strong (query, execute, list_schemas, describe_table are clear action verbs). Per-tool analysis shows consistent quality across the 9 tools, but the lack of visible output schemas and error guidance prevents a higher score.
Output schemas are not documented. The source code shows only input parameter schemas; no documentation of what fields the tools return, their types, or structure. This forces LLMs to guess the response format and causes errors when chaining tool calls.
Credentials passed as tool parameters. The 'connection' parameter accepts username and password as object fields, violating the secret-injection pattern. Credentials will appear in agent logs and traces, creating a security leak. Implement server-side secret injection via environment variables or vault.
Document output schemas for all tools. Example: 'query' returns {columns: [string], rows: [array<array>], rowsAffected: number}. Include field types and meanings so LLMs can chain tool calls.
Implement server-side secret injection. Remove username, password, and api_key from tool parameters. Store database credentials in environment variables (e.g., DB_HOST, DB_PORT, DB_USER, DB_PASS) or a secure vault. Tool parameters should accept only connection_id or a declassified connection configuration (e.g., connection_name).
Add error recovery guidance to tool descriptions. Example: 'Execute a mutating SQL statement (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, etc.). On SQL syntax error, return the error message and suggest DESCRIBE TABLE to verify column names. On permission error, return 'Access denied' and advise checking database privileges. On connection error, retry with a new connection.'
Add pagination to 'list_schemas', 'list_tables', and 'query'. Accept limit (default 20, max 1000) and offset (default 0) parameters. Return total_count and has_more fields so agents know when to paginate.
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Error handling lacks recovery guidance. Tool descriptions do not explain what errors can occur (connection failures, SQL syntax errors, permission denied) or how the LLM should respond (retry, ask user, call a different tool). This leaves agents unable to recover from failures.
Connection parameter schema is implicit. The 'connection' object is described as accepting 'db_type, host, port, database, username, password, schema, or jdbc_url' but these fields are not formally defined in a schema. No indication of which are required, what formats are valid (e.g., is port a number or string?), or what db_type values are allowed. This forces LLMs to guess.
Parameter descriptions are generic. All 8 tools repeat 'Optional connection ID to reuse existing connection' and 'Optional connection parameters object with...' without explaining connection lifetime, whether IDs persist across tool calls, or how to create a new connection. These descriptions do not guide LLM decision-making.
No pagination or result limits documented. Tools like 'list_schemas' and 'list_tables' give no indication of how many results they return, whether pagination is supported, or if results are capped. For large databases, unbounded results will exhaust context windows.
SQL injection risk in 'query' and 'execute' tools. Tool descriptions do not mention parameterization, prepared statements, or how to safely pass user input. LLMs may concatenate strings into SQL, creating injection vulnerabilities.
No permission checks or audit trail. Tool descriptions do not mention permissions (e.g., does the connection have read-only vs. write access?), nor do they commit to audit logging for compliance. Agents calling 'execute' with destructive SQL have no guardrails.
Transaction tools lack confirmation/dry-run support. 'transaction_begin', 'transaction_commit', and 'execute' do not offer a dry-run or confirmation mechanism. An agent can accidentally commit destructive changes with no opportunity to review.
Tool descriptions are under-length. Average description is ~70 characters (baseline 194 for A+ tools). Descriptions like 'Start a new transaction on the connection' lack context on WHEN to use transactions, what happens if one fails, or how transaction state relates to connection_id reuse.
Document parameterized queries. Add to 'query' and 'execute' descriptions: 'SQL must use placeholders (? for JDBC, $1 for PostgreSQL, etc.). Pass parameter values separately via a new 'parameters' array parameter, never concatenate user input into the SQL string.'
Add audit logging. Document that all tool calls log the agent ID, connection ID, SQL text, timestamp, and result status. Include a caveat: 'Credentials are never logged; use server-side secret injection.'
Support dry-run for 'execute'. Add optional 'dry_run' boolean parameter (default false). When true, execute SQL within a transaction but ROLLBACK instead of COMMIT, returning what would have been modified without actually applying changes.
Enrich parameter descriptions. Example: 'connection_id (string, optional): Connection ID returned by a previous tool call. Reusing a connection preserves transaction state and session variables. If omitted, a new connection is created for this call.' This guides LLM reasoning about connection lifecycle.
Expand tool descriptions to 100 - 200 characters. Add WHEN guidance: 'list_tables: Retrieve all tables in a schema. Call this first to discover table names before describing columns with describe_table or querying with query.'
Add result limits to tool descriptions. Example: 'query: Execute a SELECT or WITH statement and retrieve results (max 1000 rows). If more rows exist, use LIMIT and OFFSET in the SQL, or call list_tables first to apply filters.'
Gate 'execute' behind a confirmation flow. Add optional 'require_confirmation' boolean parameter. When true, return a pending confirmation object; agent must call 'confirm_execute' with the confirmation token to proceed. This prevents accidental destructive actions.
Document transaction semantics. Example: 'transaction_begin: Start a new transaction on the connection. All subsequent execute calls on this connection operate within the transaction. Call transaction_commit to apply changes, or transaction_rollback to discard. Transactions are isolated per connection_id.'
Add connection lifecycle documentation. Create a separate discovery tool (e.g., 'get_connection_info') or enrich 'connection_close' description: 'Close a specific database connection session. After closing, the connection_id is invalid and cannot be reused. All active transactions on that connection are rolled back.'