DeployFlow MCP Server

An MCP (Model Context Protocol) server that exposes deployment-safety analysis as tools an AI agent can call directly — turning static review guidance into deterministic, executable checks.

What it does

Three tools:

• deployflow_check_migration_safety — analyzes Alembic migration source for common risk patterns: no-op downgrade(), dropped columns (breaks rolling deploys), NOT NULL columns added without a server default (table-lock risk), non-concurrent index creation, and schema changes mixed with data migrations.

• deployflow_check_task_hygiene — analyzes background/worker task source for session-management issues: module-level shared DB sessions, missing explicit commit/rollback, and retryable tasks with no visible idempotency guard.

• deployflow_check_deploy_readiness — a structured pre-deploy checklist: CI status, new env vars confirmed in target, rollback plan documented.

Related MCP server: mcp-dev-workflow

Why an MCP server instead of just an LLM review

An LLM reasoning from scratch about migration safety will sometimes miss patterns or hallucinate risks. These checks are deterministic, pattern- based static analysis — the same input always produces the same output, and the logic is auditable/testable independent of any model. The MCP server lets an agent call this analysis as a tool mid-conversation, getting a guaranteed-correct result rather than an LLM's best guess.

Running it

pip install -r requirements.txt
python server.py

Connect it to Claude Code, Claude Desktop, or any MCP client by pointing the client's MCP config at this server (stdio transport by default).

Example: migration safety check

Input (Alembic migration source):

def upgrade():
    op.add_column('orders', sa.Column('priority', sa.Integer(), nullable=False))

def downgrade():
    pass

Output:

Found 2 finding(s):

[Medium] downgrade() appears to be a no-op
  Risk: This migration cannot be safely rolled back if the deploy fails.
  Fix: Implement a real downgrade() that reverses the schema change.

[High] Adding a NOT NULL column without server_default
  Risk: This will fail or require a full-table rewrite/lock on existing rows...
  Fix: Add the column as nullable, backfill in a data migration...

Tests

pytest -v

11 tests covering each detection pattern, both triggered and clean cases.

Limitations

These are pattern-based static checks, not a full AST analysis — they catch common, well-known risk patterns but are not exhaustive. Always pair with human review for anything touching production data.

Possible extensions

• Parse migrations as AST instead of regex for more precise detection

• Add a tool that diffs a migration against the current schema to detect breaking changes more reliably

• Add a tool that queries actual CI status via a CI provider's API instead of taking ci_passing as a manual input