Order Management — RBAC with MCP

Role-Based Access Control enforced inside the MCP server, not the FastAPI client. FastAPI only authenticates (issues/validates JWTs); every permission decision is made by permissions.py and applied by the MCP tools in order_checking.py.

Client -> FastAPI (auth: JWT) -> MCP Server (authz: RBAC) -> MySQL

Roles

Related MCP server: MCP Customer Support Demo

Setup

1. Create the database and tables:

   mysql -u root -p < sql/schema.sql

2. Copy .env.example to .env and fill in real values (at minimum set a strong JWT_SECRET and your real DATABASE_URL), then export them into your shell / process manager.

3. Install dependencies:

   pip install -r requirements.txt

4. Seed example users/orders (akash=ADMIN, raj=MANAGER, aman/vivek=USER managed by raj):

   python sql/seed.py

5. Run the MCP server:

   python order_checking.py

6. Run the FastAPI app (separate process/terminal):

   uvicorn main:app --reload

Usage

# Log in, get a JWT
curl -X POST http://127.0.0.1:8000/login \
  -H "Content-Type: application/json" \
  -d '{"username": "raj", "password": "managerpass123"}'

# Use the token on protected routes
curl http://127.0.0.1:8000/order_status/ORD101 \
  -H "Authorization: Bearer <token>"

curl -X POST http://127.0.0.1:8000/refund/ORD101 \
  -H "Authorization: Bearer <token>"

Files

Security notes

• The MCP server trusts the username/role passed in from FastAPI. In this design FastAPI is the only client allowed to reach the MCP server (bind it to localhost / an internal network, not the public internet) -- the JWT check happens once, at the FastAPI edge.

• Every tool call is written to audit_logs (and logs/app.log) with the outcome and reason, whether allowed or denied.

• Rotate JWT_SECRET via environment variable / secret manager -- never commit it.