Analyze SQL migration scripts to detect table locks, destructive drops, and breaking changes before execution, helping prevent database outages.
Analyze a SQL migration script for table locks, destructive drops, and breaking changes.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Raw SQL migration text to inspect. | |
| dialect | No | SQL dialect ('postgres', 'mysql', 'sqlite'). Default: 'postgres'. |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the risk categories checked, but does not clarify whether the tool only statically inspects SQL or executes anything, what permissions are required, or what the analysis result contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded sentence with no wasted words. The action and the three risk categories are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully covers the two parameters, but there is no output schema and no annotations. The description is adequate on purpose but does not describe the analysis result or behavioral constraints, leaving some gaps for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'sql' and 'dialect' parameters including the default dialect. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Analyze a SQL migration script') and names three concrete risk categories it inspects. It is clear on what the tool does, but it does not differentiate itself from siblings such as detect_table_locks, which overlaps with one of its stated checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like detect_table_locks or inspect_schema_diff. Usage is only implied by the purpose statement, with no exclusions or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.