This server has critical gaps in definition quality. While 3 tools are defined with schemas and descriptions, the descriptions are extremely minimal (10-20 chars), schemas lack critical details, and parameters expose credentials as tool inputs. The tool names are verb-based (positive), but the descriptions are dangerously terse, '获取表信息' ("get table info") and '执行 SELECT 查询语句' ("execute SELECT query") lack any guidance on WHEN to use them, WHAT they return, or how they differ. Most critically, JDBC credentials (jdbcUrl, username, password) are exposed as optional parameters in ALL three tools, violating the secret-injection pattern entirely. Parameters lack type constraints and validation guidance.
Credentials exposed as tool parameters. All three tools accept jdbcUrl, username, password as optional parameters. This violates secret-injection pattern, agent traces log all parameters, leaking credentials into logs and prompt history. Credentials must be injected server-side via environment variables or secure vault.
Descriptions are dangerously minimal (10-20 characters in Chinese). '获取表信息' ("get table info") and '执行 SELECT 查询语句' ("execute SELECT query") provide no context on WHEN to use the tool, WHAT structure is returned, dependencies between tools, or how to interpret results. LLMs cannot make informed tool selection without richer descriptions. Baseline: 194 chars average, 34-392 range.
Move JDBC credentials (jdbcUrl, username, password) out of tool parameters. Inject them server-side via environment variables (e.g. DB_URL, DB_USER, DB_PASSWORD) or a secure configuration file. If per-request database selection is required, accept a database_name or connection_id parameter instead, and resolve it to credentials internally.
Expand all three tool descriptions to 100-200 chars. Example for readQuery: 'Execute a SELECT query against the configured database and return results as structured JSON rows. Supports any SQL SELECT statement. Automatically enforces read-only (rejects INSERT/UPDATE/DELETE). Returns up to 100 rows by default; use LIMIT clause for pagination. Errors include invalid SQL syntax, table not found, and permission denied, retry guidance included in error messages.'
Document output schemas for each tool. For listTables, return: {tables: [{name: string, rowCount: number, lastModified: ISO8601}], total: number}. For listColumns, return: {table: string, columns: [{name, type, nullable, defaultValue, primaryKey}]}. For readQuery, return: {rows: [{field1, field2, ...}], rowCount: number, executionTime: number, warning?: string}.
Add pagination to readQuery. Include parameters: limit (1-1000, default 100), offset (default 0). Return: {rows: [...], rowCount: number, totalAvailable: number, hasMore: boolean}. Mention in description: 'Large results are capped at 100 rows per call; use offset to fetch subsequent pages.'
Add parameter descriptions for 'table' and 'querySql'. For table: 'Name of the database table (alphanumeric + underscore, case-sensitive on most databases). Optional schema prefix: schema_name.table_name (e.g. public.users, dbo.Orders).' For querySql: 'A valid SELECT statement. LIMIT clause recommended to cap results (default limit 100 if omitted). Only SELECT is allowed; INSERT/UPDATE/DELETE rejected with error.'
Score history
Overall score trend
↑ 10 points across a rubric change (v1 → v2)
33/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
33
2026-07-28+
v2
2026-03-09
F
23
-
v1
Parameters lack descriptions for 'table' and 'querySql'. While 'table' has description '数据库表名' ("database table name") and 'querySql' has '查询语句' ("query statement"), these are single-word summaries in Chinese, not actionable parameter guidance. Required parameters must explain: expected format, constraints (e.g. 'table name must be alphanumeric, max 64 chars'), and any special handling (e.g. 'schema.table syntax supported'). Baseline: 72 chars average per param description.
No output schemas documented. It is unknown what fields listTables, listColumns, and readQuery return, their types, and nesting. LLMs cannot plan downstream tool calls or extract data without documented return types. Example: does listTables return [{name, type, columns}] or {tables: [...], metadata: {...}}? Does readQuery return raw tuples or structured objects?
No pagination or result limiting specified. A query like 'SELECT * FROM huge_table' via readQuery could return millions of rows. The tool description does not mention pagination parameters (limit, offset), max result count, or warnings about large datasets. Without limits, results can blow the context window.
No error handling or recovery guidance. Tool descriptions do not explain what happens on invalid SQL, missing tables, connection failures, or permission errors. Errors should be categorized (retryable vs. user-fixable) and include actionable guidance. E.g. 'Table not found. Available tables: [...]' instead of a bare 404.
Optional JDBC parameters on all tools create ambiguity. If jdbcUrl, username, password are optional, what is the default behavior? Does the server use a single hardcoded connection? Does it maintain per-request state? The description should clarify: are these per-request overrides, or does the server only support one database? This affects idempotency and composition.
No SQL injection protection documented. readQuery accepts 'querySql' as a free-form string. The description should clarify: does the tool sanitize/parameterize? Does it reject certain keywords (DROP, DELETE, INSERT)? Are there permissions checks to prevent unauthorized data modification? LLMs can be tricked into passing malicious SQL.
No tool composition hints. There is no documentation on the relationship between listTables, listColumns, and readQuery. Does an agent call listTables first to discover available tables, then listColumns for schema, then readQuery for data? The descriptions should include dependency hints to guide multi-step workflows.
listTableslistColumnsreadQuery
Document error scenarios and recovery. Example: 'On table not found, the tool returns: {error: "Table \"xyz\" does not exist", availableTables: ["users", "products", ...]}. On SQL syntax error: {error: "SQL syntax error at position 42: unexpected token...", suggestion: "Did you mean: SELECT * FROM users?"}. On permission denied: contact your database administrator.'
Add security guidance in descriptions. Example for readQuery: 'This tool enforces read-only mode, all INSERT, UPDATE, DELETE, DROP statements are rejected. Parameter values are parameterized to prevent SQL injection. Query execution is logged for audit purposes. Sensitive columns (passwords, tokens) should be masked server-side before returning to the agent.'
Document tool relationships and call order. Example: 'Discovery workflow: (1) Call listTables to see available tables and row counts. (2) Call listColumns on a specific table to understand its schema. (3) Call readQuery to fetch data. Example: agent discovers schema → generates appropriate SELECT → retrieves results.'
Add idempotency and state assumptions. Example: 'All three tools are read-only and stateless. Repeated calls with identical parameters return identical results. No state is maintained between calls. Optional JDBC parameters, if provided, override server defaults for that request only.'
Translate descriptions to English or provide English + Chinese. Current Chinese descriptions are inaccessible to most LLM systems and tool documentation consumers. Use: 'Get table information' → 'Discover available tables in the database, including row counts and metadata' (100+ chars, action-oriented).