Loading ToolBench
MCP server for analyzing PostgreSQL migrations for safety issues, providing AI assistants with migration analysis tools.
MigrationPilot MCP server demonstrates solid definition quality with well-structured tools, clear naming conventions, and comprehensive descriptions. All 7 tools follow verb_noun naming (analyze_*, suggest_*, explain_*, list_, check_*, get_). Descriptions average ~150 chars, within the 10-1024 baseline. All tools have explicit input schemas with typed parameters and descriptions. However, output schemas are not documented in the source code visible, tool responses are inferred from descriptions rather than formally specified. Error handling guidance is minimal; no recovery patterns or actionable error messages are evident. Tool composition is excellent: each tool has a single responsibility, names clearly distinguish related tools (analyze_migration vs analyze_migration_dir vs check_before_apply), and parameters use clear naming (pg_version, configPath, ruleId). Security is strong: no credentials exposed as parameters, read-only operations dominate, one reversible operation (suggest_fix) is properly marked. The check_before_apply tool is particularly well-designed, resolving config from the project exactly as the CLI does and returning a pass/fail verdict to prevent unsafe migrations.
Analyze a PostgreSQL migration SQL for safety issues. Returns violations, risk level, and lock analysis.
Analyze every migration file in a directory (or glob pattern) for safety issues. Returns aggregated violations and per-file breakdowns.
Safety gate: call this BEFORE writing or executing any PostgreSQL DDL or migration. Resolves the project's own MigrationPilot config (rule toggles, severity overrides, failOn threshold) exactly like the CLI, then returns a pass/fail verdict. On "fail", do not apply the migration — fix the blocking violations and check again.
Explain what PostgreSQL lock a DDL statement acquires and its impact.
Full documentation for one rule, including rationale, examples, and safe alternatives.
List all available MigrationPilot safety rules with descriptions.
Output schemas are not documented. Tool descriptions explain what is returned ('violations, risk level, and lock analysis' for analyze_migration; 'pass/fail verdict' for check_before_apply) but the JSON structure and field types are not formally specified. LLMs cannot plan downstream operations or extract fields reliably without explicit output schema documentation.
No error handling guidance. Tools lack recovery patterns or actionable error messages. If analyze_migration receives invalid SQL, the response likely returns a raw error rather than 'Invalid SQL syntax at line X. Common issues: missing semicolon, unsupported statement type. Refer to PostgreSQL docs: <link>'. Agents cannot self-correct without explicit guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Auto-fix safe violations in a PostgreSQL migration SQL. Returns the fixed SQL and list of changes.
list_rules has an empty input schema ({}). The description says 'List all available MigrationPilot safety rules with descriptions.' but does not document pagination, filtering, or result limits. If there are hundreds of rules, returning all of them in one call wastes tokens and risks context exhaustion.
get_rule parameter 'ruleId' description is minimal ('The rule ID (e.g. MP001)'). It does not state: is the format case-sensitive? Are aliases supported (MP001 vs mp001)? What happens if the rule does not exist? Minimal descriptions force LLMs to guess.
check_before_apply has three optional parameters (pgVersion, configPath) with defaults, but the logic is complex: 'Defaults to the config's pgVersion, or 17' and 'resolves config from... searching upward'. This multi-step resolution is not explicit in the parameter description. If the agent does not understand the config resolution order, it may pass a configPath that is ignored or misinterpreted.