# 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.

## 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

```bash
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):

```python
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

```bash
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