Coderift MCP Project

Overview

Coderift Technologies is a B2B software company. Customers submit feature requests continuously, and internal employees need to review, prioritize, and approve them without touching the production database directly. This project is an MCP server sitting in front of that database, plus a client that talks to it through the protocol instead of raw SQL.

Related MCP server: safe-migrations-mcp

The Problem

Before this system, support agents queried the database directly (or asked an engineer to) whenever a customer asked about a request's status, and a product manager approved requests from a spreadsheet with no audit trail and no check on how many customers a change actually affected. Two things made this risky enough to justify a real protocol-aware server instead of a thin CRUD wrapper:

1. Approvals are not all equal. Approving a request that affects 800 customers is a different decision than approving one that affects 40. The naive version either lets any agent approve anything, or hard-codes a blanket rule that ignores context. We wanted a manager to have to explicitly sign off on high-impact approvals, live, not just trust a role field the caller sends us.

2. Roles change mid-session. A support agent gets promoted to product manager during their shift (or a manager is filling in). The tool set available to them should change the moment that happens, not after they reconnect.

Those two facts are what justify elicitation and notifications in this system, not a rule bolted on for the assignment. Report generation over the full pending-request backlog is also genuinely slow-ish and benefits from progress feedback instead of a blocking call.

Database & ERD

Engine: SQLite (db/coderift.db, built from db/schema.sql + db/seed.sql via db/create_db.py).

Tables: customers, employees, feature_requests (FK to customers), approvals (FK to feature_requests and employees, for a future audit trail). Seed data covers both roles, all three statuses (Pending, Approved, Rejected), and both sides of the 500-customer elicitation threshold (a 40-customer request, a 500-customer boundary case, and an 800-customer request).

Project Structure

coderift-mcp/
├── db/
│   ├── schema.sql
│   ├── seed.sql
│   ├── create_db.py
│   ├── ERD.png
│   └── coderift.db        (generated)
├── mcp_server/
│   ├── server.py
│   └── models.py
├── agent/
│   └── client.py
├── requirements.txt
└── README.md

Installation

python -m venv .venv
source .venv/bin/activate      # .venv\Scripts\activate on Windows
pip install -r requirements.txt
python db/create_db.py

Running

# server, local development
cd mcp_server
python server.py                              # stdio (default)
python server.py --transport streamable-http --port 8000   # remote

# agent, in a second terminal
cd agent
python client.py                # stdio, spawns server.py itself
python client.py --http http://127.0.0.1:8000/mcp   # against a running HTTP server

Set ANTHROPIC_API_KEY before running the agent to have the sampling callback use a real model; otherwise it uses a labeled stub response so the demo still runs end to end.

Where each protocol concern lives

Comparison note

If a client connects without elicitation support, approve_feature_request refuses to silently approve a high-impact request — it returns a structured elicitation_unsupported error explaining that a manager needs to approve it out of band. If a client connects without sampling support, generate_feature_analysis still returns a usable (if less nuanced) rule-based risk rating instead of failing.

Transport choice, justified

Development happens over stdio — no server process to manage, easy to run from the agent script directly, matches how one developer iterates locally. server.py also runs over Streamable HTTP (--transport streamable-http), which is the right choice once Coderift's own product managers across multiple offices need to hit the same server concurrently instead of each spawning their own local process — a single deployed HTTP endpoint sits behind normal auth/network controls, which stdio can't do. Both paths share the same tool/resource/prompt code; only the transport layer changes.

Demonstration Workflow

agent/client.py runs, in order: initialize + capability check, list tools as a support_agent, an unauthorized change_priority attempt, promote_to_manager (real employee lookup + real notification), tool list re-fetch showing the unlocked write tools, generate_impact_report with live progress, approve_feature_request on an 800-customer request (elicitation fires) and a 40-customer request (it doesn't), sampling-backed generate_feature_analysis, change_priority, a resource read, and a prompt fetch.

Where it stands now

Session role state lives in a process-local dict keyed by session id, which is fine for the stdio demo and a single-process HTTP deployment but wouldn't survive a restart or a multi-instance deployment — a production version would move that to a signed session token or a real auth layer instead. The approvals table exists in the schema for an audit trail but isn't written to yet; that'd be the next addition, along with a director review tier for requests over 1000 affected customers as described in the approval-guidelines resource.

Technologies Used

Python, MCP Python SDK (mcp), SQLite, Pydantic, rank_bm25.