dbmcp is a STDIO-only database introspection tool with 4 read-only tools. Tool definitions are visible in dbmcp/tools.go with explicit input/output structs and JSON schema tags. However, the server has significant quality gaps: (1) Descriptions are present but generic and lack LLM-optimization guidance; (2) Parameter descriptions exist but are minimal (e.g., 'optional; database connection id' lacks context on when to use it); (3) No output schema documentation, only inferred from code; (4) No error handling guidance for the LLM (e.g., what to do if a query fails or table doesn't exist); (5) No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only; (6) No pagination support despite run_select_query potentially returning large result sets. The tools themselves are well-structured and follow a consistent pattern, but lack the depth needed for robust LLM reasoning.
Get detailed information about a table including columns, types and primary key
Get database information like name, version and connection status
Get list of all tables in the database
Run a SELECT query to retrieve data from the database
Output schemas are undocumented in tool registration. LLMs cannot plan downstream actions without knowing the structure of results. get_database_info returns GetDatabaseInfoOutput struct (database_name, database_vendor, database_version, connection_status), but this is inferred from code, not declared in the tool's output schema field.
No error recovery guidance. run_select_query has a query validation check ('only SELECT queries allowed'), but error messages are not returned with actionable next steps. If a query fails or a table doesn't exist, the LLM receives a bare error with no guidance on how to recover.
No pagination support in run_select_query. If a SELECT returns thousands of rows, the entire result set is returned, potentially exhausting context window. No limit, offset, or cursor parameters present. Baseline pattern expects paginated results for tools returning lists.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Parameter descriptions are too brief and lack context. The 'connection_id' parameter on all tools says 'optional; database connection id. If omitted, the server default connection is used', this doesn't explain when or why an LLM would pass a non-default connection, or what happens if the connection ID doesn't exist.
No tool annotations despite clear read-only semantics. All tools are READ_ONLY (marked in the source), but the MCP tool definitions lack readOnlyHint annotation. This leaves LLMs uncertain about whether a tool modifies state, forcing conservative reasoning and redundant confirmations.
Tool descriptions lack LLM-optimization. Descriptions are 40-50 characters and do not explain WHEN to use each tool instead of another or WHAT subsequent actions become possible. E.g., 'Get database information like name, version and connection status' doesn't say why you'd call this before other tools, or whether it validates connectivity.