Skip to main content
Glama
possibly6

safe-migrations-mcp

by possibly6
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Safe Migrations MCP

Your AI coding agent can silently destroy your production database.

A misplaced DROP COLUMN, a missing WHERE, a one-character .env typo — Claude Code, Cursor, OpenClaw, and every other coding agent will cheerfully execute the change and report success while your data quietly vanishes.

This was born from watching an OpenClaw agent break its own config file trying to make a "small" change. The fix turned out to be universal: any agent that can edit anything should have to slow down, show its work, and ask first.

Safe Migrations MCP is the gate they have to pass through first. Every proposed schema change or config edit is diffed, risk-flagged, snapshotted, and requires a one-time confirmation token from a fresh simulate_impact call before a single byte is written.

Works with any MCP-capable agent. Local-first. Zero cloud dependency.

How it works

The mandatory checkpoint between the agent and your disk:

  1. Propose — agent sends an intent (natural language, raw SQL, or a new config file); server returns a proposal_id plus a redacted preview and SHA-256 hash of the SQL/edit and its rollback. Full payload is stored server-side, never echoed back.

  2. Simulate — dry-run inside a rolled-back transaction; count affected rows; surface every DROP, TRUNCATE, NOT-NULL-without-default, secret-key removal, etc. On success, returns a one-time confirmation_token bound to the proposal's fingerprint.

  3. Apply — only runs with that fresh confirmation_token. Snapshots the file or DB first. Logs everything to an append-only audit trail.

~2k LOC of Python, hardened against the usual footguns (symlink writes, silent SQLite creation, MySQL DDL auto-commit, token replay, secret leakage in diffs).

Related MCP server: impact-preview

Install & run

pip install safe-migrations-mcp          # or: pipx install safe-migrations-mcp
safe-migrations-mcp                      # speaks MCP over stdio

Or from a local clone:

git clone https://github.com/possibly6/safe-migrations-mcp
cd safe-migrations-mcp
pip install -e '.[all]'
safe-migrations-mcp

Optional extras (Postgres / MySQL drivers):

  • pip install 'safe-migrations-mcp[postgres]' — adds psycopg

  • pip install 'safe-migrations-mcp[mysql]' — adds PyMySQL

  • pip install 'safe-migrations-mcp[all]' — both

SQLite, YAML, JSON, .env, and Prisma/Drizzle schema-file parsing work with zero extra deps.

Wire it into your agent

Claude Code / Claude Desktop

~/.claude/claude_desktop_config.json (or ~/.config/Claude/claude_desktop_config.json on Linux):

{
  "mcpServers": {
    "safe-migrations": {
      "command": "safe-migrations-mcp"
    }
  }
}

Cursor

~/.cursor/mcp.json:

{
  "mcpServers": {
    "safe-migrations": { "command": "safe-migrations-mcp" }
  }
}

OpenClaw / any MCP-capable agent

Point the agent at the safe-migrations-mcp binary on stdio. The tool names match the list below.

The 8 tools

Tool

Purpose

inspect_schema(connection)

Current DB/ORM schema. Postgres, MySQL, SQLite, plus schema.prisma and Drizzle TS files. Cached 60s.

inspect_config(path)

Parse YAML / JSON / .env / Prisma / TOML; return keys and shape.

propose_migration_or_edit(kind, …)

Create a proposal from natural language, raw SQL, or a new config file. Returns proposal_id plus redacted previews and hashes. Nothing is written.

simulate_impact(proposal_id)

Dry-run the proposal. DB: rolled-back transaction + affected-row count + SQL/rollback previews. Config: unified diff + key delta. Always returns risk flags.

generate_rollback(proposal_id | sql)

Exact undo SQL (or the config-snapshot restore path).

apply_change(proposal_id, confirmation)

Requires the fresh confirmation_token from simulate_impact. Snapshots first, then executes in a transaction.

get_change_history(limit)

Append-only audit log of every applied change.

cleanup_state(max_age_days)

Prune old proposal metadata, secret payloads, and snapshots from local state.

Example agent conversation (the confirmation flow)

You: "Add a last_login timestamp column to users in ./demo.db."

Agent (silently): propose_migration_or_edit(kind="db", connection="sqlite:///./demo.db", request="add column last_login of type TEXT to users")

→ proposal_id = p_9a1b2c3d4e, sql_preview = ALTER TABLE "users" ADD COLUMN "last_login" TEXT;, rollback_preview = ALTER TABLE "users" DROP COLUMN "last_login";

Agent (silently): simulate_impact("p_9a1b2c3d4e")

→ risk_level = "low", dry_run.ok = true, affected_rows = 0

Agent (to you):

I'd like to run: ALTER TABLE "users" ADD COLUMN "last_login" TEXT; Risk: low. Rollback available. Confirm?

You: "yes, confirm"

Agent (silently): copies the confirmation_token from simulate_impact(...) and calls apply_change("p_9a1b2c3d4e", "<that token>") → done, audit logged.

And the dangerous case:

You: "drop the orders table."

Agent (silently): propose_migration_or_edit(kind="db", ..., sql="DROP TABLE orders;") → simulate_impact(...) returns risk_level: "critical", flag: "Drops an entire table (all data lost)".

Agent (to you):

🛑 This is a critical destructive change on 3 rows. Rollback can recreate the table but row data cannot be auto-restored without a backup. Are you sure? Reply with the exact confirmation_token from the simulation step to proceed.

The agent physically cannot execute until that token is passed through — the server enforces it, not the model.

Example prompts you can paste

Claude / Cursor / OpenClaw:

Use the safe-migrations MCP. Inspect sqlite:///./examples/demo.db.
Then propose adding a `phone` TEXT column to users (nullable).
Show me the proposal + simulated risk. Wait for my approval before applying with the confirmation token from simulate_impact.
Use safe-migrations to edit ./examples/config.yaml: set app.log_level to "debug".
Show the diff and risk first. Only apply after I confirm.
Use safe-migrations to audit recent changes — call get_change_history and
summarize the last 10 entries.

Try the demo locally

git clone https://github.com/possibly6/safe-migrations-mcp
cd safe-migrations-mcp
pip install -e .
python examples/seed_demo.py            # creates examples/demo.db
safe-migrations-mcp                     # start the server

Then, from your MCP-connected agent:

  • inspect_schema("sqlite:///./examples/demo.db")

  • inspect_config("./examples/config.yaml")

  • propose_migration_or_edit(kind="db", connection="sqlite:///./examples/demo.db", request="create index on orders(status)")

  • simulate_impact(...) → apply_change(..., "<confirmation_token>")

What gets flagged

SQL risk rules (severity):

  • DROP TABLE / DROP DATABASE / DROP SCHEMA — critical

  • DROP COLUMN, TRUNCATE, DELETE/UPDATE without WHERE — high

  • ALTER COLUMN … TYPE, RENAME TO, ADD COLUMN NOT NULL without DEFAULT, GRANT/REVOKE — medium

Config risk rules:

  • Removal of keys matching database|db|auth|secret|token|production|prod|migration — high

  • Adding or changing values on keys matching password|secret|api_key|token|private_key|database_url|dsn|credentials — medium

  • Any removed key — at least medium

Anything ≥ medium sets confirmation_required: true. High-risk config changes are blocked from direct apply so the agent has to reduce scope or hand the edit back for manual review.

State & audit

All local, all visible:

~/.safe-migrations-mcp/
├── proposals/    # redacted proposal metadata as JSON
├── secrets/      # private proposal payloads (0600), pruned with cleanup_state
├── snapshots/    # pre-change backups
└── audit.jsonl   # append-only log of applied changes (redacted)

Override with SAFE_MIGRATIONS_HOME=/path.

When to use this

✅ Use Safe Migrations MCP when:

  • You let an AI agent touch your database or config files

  • You want every schema change diffed and confirmed before it runs

  • You want an audit trail of every change an agent has ever made

  • You want rollback SQL generated automatically

  • You're tired of agents silently dropping columns or rewriting .env files

❌ Use a real migration framework (Alembic / Prisma Migrate / Flyway) when:

  • You need versioned, repeatable migrations checked into source control

  • You're running zero-downtime migrations on a production Postgres

  • You need MySQL DDL apply support (this server intentionally blocks it — see FAQ)

  • You want online schema changes / backfills / dual-writes

This is a gatekeeper, not a migration framework. They're complementary — author your migrations with Alembic, let agents propose runtime tweaks through this.

In scope: SQLite, Postgres, MySQL inspection / DML; YAML, JSON, .env, Prisma, Drizzle (best-effort). Natural-language intents for common DDL (add/drop/rename column, create index, drop table). Raw SQL pass-through with automatic best-effort rollback.

Out of scope (on purpose): MySQL DDL apply, full SQL dialect coverage, online schema migrations, arbitrary DSL translation. Safety and clarity beat breadth here — if a proposal is outside what we can analyze, we say so instead of guessing.

FAQ

Q: How is this different from Alembic, Prisma Migrate, or Flyway? A: Those are migration frameworks — they track, version, and apply schema changes you author by hand. This is a gatekeeper — it sits between an AI agent and your DB/configs and forces every change through diff → simulate → confirm → apply. Use both.

Q: Can the agent bypass the confirmation token? A: Not from inside this server. The token is generated server-side, bound to a SHA-256 fingerprint of the proposal, and expires in 15 minutes. Editing the proposal invalidates the token. The agent must call simulate_impact to get a fresh one — and the client UI (Claude Code's prompt, Cursor's confirm dialog) is what makes a human actually read the proposal before that token gets passed back.

Q: Does this work in CI? A: It's the wrong tool for CI. The whole point is a human checkpoint. In CI, use your normal migration framework with version-controlled SQL. Reach for this server when an agent (Claude Code, Cursor, OpenClaw) is the one proposing the edit.

Q: What happens if the apply fails halfway through? A: SQLite changes run inside a transaction and roll back on error. Postgres applies via psycopg with explicit commit/rollback. Failed applies are marked apply_failed, not applied, and audited as a separate event so you can find them later.

Q: Why is MySQL DDL apply intentionally blocked? A: MySQL auto-commits DDL — there's no real "dry-run inside a transaction" or rollback. This server refuses to pretend it has a safety net it doesn't have. MySQL DML (INSERT/UPDATE/DELETE) and inspection still work fine.

Q: Does it know about my Postgres triggers, views, or functions? A: Not in v0.1 — inspection covers tables and columns. Triggers/views/functions are out of scope for now.

Q: My agent has a raw write_file tool too. Can't it just bypass the MCP? A: Yes — the safety is opt-in at the agent's tool level. If you wire safe-migrations in and leave a raw filesystem write tool enabled for the same paths, the agent can route around the gate. The intended pattern is: route DB and config edits through this server, and keep raw filesystem writes scoped to other paths.

Development

pip install -e '.[all]'
pip install pytest
pytest -q

License

MIT.

Available Tools

8 tools
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.

ParametersJSON Schema
NameRequiredDescriptionDefault
proposal_idYes
confirmationYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description covers key behaviors: requires confirmation, snapshots files, executes in a transaction, and logs audit entries. This gives the agent a good understanding of side effects, though it misses details on failure handling or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences and a bullet-like list. It efficiently communicates purpose, prerequisite, and actions without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity and presence of an output schema, the description covers the essential aspects: it states what the tool does, prerequisites, and internal actions. It does not describe the return value, but output schema exists to cover that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description only mentions 'confirmation token' without explaining its format or relationship to the parameter. The proposal_id parameter is not described. This leaves the agent guessing about parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it applies a proposal and requires a confirmation token from simulate_impact. It gives a clear purpose, though it does not explicitly differentiate from sibling tools like propose_migration_or_edit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the prerequisite of a one-time confirmation token from simulate_impact. It implies when to use the tool (after simulation), but does not provide when-not-to-use or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cleanup_stateB

Prune old proposal metadata, secret payloads, and snapshots from local state.

ParametersJSON Schema
NameRequiredDescriptionDefault
max_age_daysNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It indicates destructive action ('prune') but lacks details on irreversibility, side effects, or safety considerations. The agent has no indication of data recovery options or whether the operation is safe to run regularly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the core action and objects. It is front-loaded and to the point, though it could benefit from slightly more structure (e.g., listing items or parameter clarification).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description omits return value information, side effects, or any process details. Given the lack of annotations and the tool's potentially destructive nature, the description is insufficient for comprehensive understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description only vaguely references 'old' data. However, the single optional parameter (max_age_days) is hinted at by the word 'old', and the default value is clear from the schema. The description adds minimal meaning beyond the schema's own structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's action ('prune') and the specific items (proposal metadata, secret payloads, snapshots) and location (local state), distinguishing it from sibling tools like apply_change or inspect_config.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use cleanup_state versus alternatives, nor are there any prerequisites or exclusions mentioned. The description simply states what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_rollbackA

Produce exact undo SQL (for DB proposals) or a restore plan (for config).

Either pass an existing proposal_id, or pass raw sql (+ optional connection for better schema-aware rollbacks).

ParametersJSON Schema
NameRequiredDescriptionDefault
proposal_idNo
sqlNo
connectionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states the tool produces rollback plans but does not disclose whether it is read-only, what permissions are needed, or any side effects. No mention of output format despite having an output schema. Behavioral traits like rate limits or error handling are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, no fluff, and front-loaded with key information. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters and no annotations, the description covers the two modes adequately. It does not explain output schema or limitations, but an output schema exists, reducing the burden. Slight gaps on conditional behavior (e.g., what happens if both proposal_id and sql are provided) prevent a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning: it explains that proposal_id and sql are mutually exclusive, and that connection is optional for schema-aware rollbacks. This significantly aids parameter understanding beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool produces undo SQL for DB proposals or a restore plan for config, distinguishing it from sibling tools like apply_change or simulate_impact. It specifies two distinct usage modes (by proposal_id or by sql+connection), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for generating rollbacks but lacks explicit guidance on when to use this tool versus alternatives. No mention of when not to use it or comparisons to siblings like simulate_impact or propose_migration_or_edit. The word 'either' helps but is insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_change_historyC

Return the audit log of applied changes (most recent last).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It only discloses ordering ('most recent last') but omits important behavior: no mention of pagination, default limit, or that only recent changes are returned. The 'limit' parameter is not explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no superfluous words. However, it sacrifices completeness for brevity by omitting parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and a single parameter, the description is incomplete. It fails to mention what the output contains or how to control the result size via 'limit', leaving the agent with insufficient information for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage. The description does not explain the 'limit' parameter at all, leaving the agent to guess its purpose or bounds. It adds no value beyond the schema's default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns an 'audit log of applied changes' with ordering 'most recent last'. It identifies the resource and a key behavioral attribute, but does not differentiate from sibling tools like 'generate_rollback'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'inspect_config' or 'simulate_impact'. The description lacks context for when the audit log is the appropriate choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_configC

Parse and summarize a config file (YAML/JSON/.env/Prisma/TOML/text).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description bears full burden. It does not disclose whether the tool is read-only, what side effects occur (e.g., locking, caching), or authentication needs. 'Parse and summarize' implies reading but no explicit confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource, making it efficient. However, it sacrifices necessary detail for brevity, which slightly limits its effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description omits behavioral characteristics like error handling, output format summary, or differences in parsing across file types. The tool's simplicity (1 param) reduces the gap, but the description remains insufficient for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond the schema. It does not explain the path parameter's expected format, location, or constraints (e.g., relative vs absolute). The supported file types are listed but not tied to the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool parses config files and lists supported formats (YAML/JSON/.env/Prisma/TOML/text), which distinguishes it from sibling tools like inspect_schema. However, 'summarize' is somewhat vague, and the tool's exact scope could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like inspect_schema or generate_rollback. The description lacks context about appropriate scenarios or prerequisites (e.g., file must exist, must be readable).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_schemaA

Inspect a database or ORM schema file.

connection examples:

  • sqlite:///path/to/app.db OR ./app.db

  • postgresql://user:pw@host/db

  • mysql://user:pw@host/db

  • ./prisma/schema.prisma

  • ./drizzle/schema.ts

Results are cached locally for 60s unless refresh=True.

ParametersJSON Schema
NameRequiredDescriptionDefault
connectionYes
refreshNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions caching behavior (60s cache unless refresh=True), which is helpful, but does not state whether the tool is read-only, any authentication requirements, or potential side effects. The description is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: a single sentence followed by connection examples and a caching note. It is well-structured and easy to scan. Minor improvement would be front-loading the caching behavior more prominently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to explain return values. It adequately covers input parameters and caching. For a schema inspection tool, it provides sufficient context for an agent to understand usage, though it lacks guidance on connecting to different database types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no descriptions (0% coverage), so the description must compensate. It provides connection examples for the 'connection' parameter and explains the caching effect of 'refresh'. This adds significant meaning beyond the schema alone, though it could detail connection string formats more systematically.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action (inspect) and resource (database or ORM schema file). It provides concrete connection examples, making the purpose unambiguous. The tool name 'inspect_schema' further reinforces this, and sibling tools like 'apply_change' and 'simulate_impact' are clearly distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention situations where it is inappropriate or suggest other tools like 'inspect_config' for different schema aspects. No preconditions or contexts are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 request path: (config) path to the file being edited new_content: (config) full new file contents

Nothing is written. Call simulate_impact(proposal_id) next, then apply_change with the one-time confirmation_token returned by the simulation step.

ParametersJSON Schema
NameRequiredDescriptionDefault
kindYes
connectionNo
requestNo
sqlNo
pathNo
new_contentNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explicitly states 'Nothing is written' and describes workflow with proposal_id and one-time token. Explains parameter priority (sql over request). No annotations exist, so description carries full burden; it does well but could add more on error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose, structured bullet list for parameters. Efficient but not perfectly concise; still clear and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, workflow, and next steps. Output schema exists so return details not needed. Could add error handling or validation notes, but sufficient for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates fully by explaining each parameter's purpose, context (e.g., kind='db' or 'config', connection for db, path for config), and behavior (sql takes priority over request).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool proposes either a DB migration or config edit, returns a proposal_id, and distinguishes from sibling apply_change. The description uses specific verbs and resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: use this to create proposals before applying changes, with explicit next steps (simulate_impact, apply_change). However, lacks explicit when-not-to-use or alternatives beyond the workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
proposal_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description effectively communicates key behaviors: dry-run nature, rolled-back transactions for DB, diff for config, risk flags, and confirmation requirement, which is thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, each serving a clear purpose without redundancy, and front-loaded with the core concept 'Dry-run a proposal.'

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description covers the different behaviors for DB and config proposals, risk flags, and confirmation requirements adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter proposal_id is not described beyond its name, and schema coverage is 0%. Despite the tool's behavior being explained, no information about the format, constraints, or valid values for the parameter is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool as a dry-run for proposals, specifying different behaviors for DB proposals (rolled-back transaction) and config proposals (diff + key delta), which is specific and distinctive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for testing before applying changes but does not explicitly state when to use versus alternatives like apply_change or propose_migration_or_edit, nor does it mention when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.0
    • First observedapply_change
    • First observedcleanup_state
    • First observedgenerate_rollback
    • First observedget_change_history
    • First observedinspect_config
    • First observedinspect_schema
    • First observedpropose_migration_or_edit
    • First observedsimulate_impact
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: proposing, simulating, applying, rolling back, inspecting config/schema, getting history, and cleanup. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern (e.g., apply_change, inspect_schema). Verbs are descriptive and standardized.

Tool Count5/5

8 tools is well-scoped for a migration server. It covers the core workflow without being excessive or insufficient.

Completeness5/5

The tool surface covers the full migration lifecycle: propose, simulate, apply, rollback, history, inspection, and cleanup. No obvious gaps for its intended domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • agami-core

    redseerdigital
    F
    license
    Not graded
    quality
    B
    maintenance
    A governed MCP server that enforces a trust layer between AI agents and databases, requiring sign-off on joins and metrics and producing auditable receipts for every query.
    -

  • impact-preview

    agent-polis
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server that provides impact preview and approval workflow for AI agent actions, allowing users to see diffs and risk assessments before any changes are executed.
    1
    MIT

  • Vantex-Security-A

    farahkhaterr
    F
    license
    Not graded
    quality
    B
    maintenance
    This MCP server provides secure access to databases for AI agents, enforcing authentication, authorization, human approval, logging, and notifications to prevent dangerous actions.
    -

  • enterprise-mcp

    dbett4
    A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server exposing scoped, read-only enterprise operations tools with fail-closed credential handling. It returns opaque approval IDs for mutations and requires a separate operator approval command to release one-time capabilities.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/possibly6/safe-migrations-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server