XAMPP MCP provides four database tools with complete JSON schemas and non-trivial descriptions. Naming is clear and verb-forward (db_create, db_export, db_import, db_inspect). All tools have input schemas with typed parameters and descriptions. However, descriptions are generic (averaging ~60 chars) and lack LLM-optimized guidance on WHEN to use each tool or HOW to chain them. No output schemas are documented. Error handling is present but minimal, no recovery guidance or actionable error messages. Missing key production patterns: no pagination for db_inspect results, no result limits documented, no guidance on parameter dependencies (all tools accept host/port/user/password, creating repetition). Confirmation flow is implemented but the 'confirmed' parameter pattern is verbose. Tool composition is reasonable but could benefit from stronger chaining hints.
Creates a MySQL database
Exports a MySQL database to a SQL file
Imports SQL file into a MySQL database
Shows database status summary with table-level information
Descriptions lack WHEN/WHY guidance and are under 100 chars. 'Creates a MySQL database' tells the LLM WHAT but not WHEN to prefer db_create over manual execution, or how it chains with db_inspect. LLM-optimized descriptions should be 50 - 200 chars and include context.
No output schemas documented. db_inspect result structure is not declared, LLM cannot plan downstream calls or extract table names for chaining to db_export. Output schemas are critical for composition.
All four tools expose host/port/user/password as parameters. This violates secret-injection pattern and forces repetition. MySQL credentials should be injected server-side via environment; tools should use default or optional overrides only.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
No documented limits or pagination for db_inspect. If a database has thousands of tables, the full response may exhaust context. Rubric baseline: A+ tools cap results at 20 - 50 items and offer pagination. Current implementation offers no guidance.
Confirmation pattern uses a 'confirmed' boolean parameter. This is verbose for the LLM. Modern pattern (MRTR / input_required) is implemented in app.ts but parameter-based confirmation remains. Consider deprecating 'confirmed' in favor of pure input_required flow.
Error handling in tools (src/tools/*.ts) not visible in provided code. app.ts shows error interception and toToolErrorResult() but actual tool implementations are not provided. Cannot verify actionable error messages or recovery guidance.