safe-migrations-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SAFE_MIGRATIONS_HOME | No | Override the default state directory (~/.safe-migrations-mcp/) with this path. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_schemaA | Inspect a database or ORM schema file. connection examples:
Results are cached locally for 60s unless refresh=True. |
| inspect_configC | Parse and summarize a config file (YAML/JSON/.env/Prisma/TOML/text). |
| propose_migration_or_editA | Propose a DB migration OR a config edit. Returns a proposal_id you pass to apply_change. Args:
kind: 'db' or 'config'
connection: (db) connection string or schema-file path
request: (db) natural-language intent, e.g. "add column email of type TEXT not null default '' to users"
sql: (db) raw SQL — takes priority over Nothing is written. Call simulate_impact(proposal_id) next, then apply_change with the one-time confirmation_token returned by the simulation step. |
| simulate_impactA | Dry-run a proposal. DB proposals execute inside a rolled-back transaction to surface errors and count affected rows. Config proposals show full diff + key delta. All results include risk flags and whether explicit confirmation is required. |
| generate_rollbackA | Produce exact undo SQL (for DB proposals) or a restore plan (for config). Either pass an existing proposal_id, or pass raw |
| apply_changeA | Apply a proposal. Requires the one-time confirmation token from simulate_impact. Before writing, snapshots the affected file (configs) or the SQLite file, then executes inside a transaction where possible. Logs an audit entry. |
| get_change_historyC | Return the audit log of applied changes (most recent last). |
| cleanup_stateB | Prune old proposal metadata, secret payloads, and snapshots from local state. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: proposing, simulating, applying, rolling back, inspecting config/schema, getting history, and cleanup. No overlap in functionality.
All tools follow a consistent verb_noun naming pattern (e.g., apply_change, inspect_schema). Verbs are descriptive and standardized.
8 tools is well-scoped for a migration server. It covers the core workflow without being excessive or insufficient.
The tool surface covers the full migration lifecycle: propose, simulate, apply, rollback, history, inspection, and cleanup. No obvious gaps for its intended domain.