Repo on GitHub →
A framework I built for myself · Open source · MIT

This is what I use to give my Django apps an MCP server.

It turns Django models into MCP tools and a REST API from one class. If you don't have Django, 0-mcp init reads a MySQL or Postgres schema and generates the whole project. I run it in six of my own products.

I'm sharing it because someone might find it useful, and because I'd like help making it better. — Stamatios Stamou Jr
Install

Three flavors. Pick one.

Framework only, or with the introspector if you want to point it at an existing database.

$ pip install 0-mcp # framework only $ pip install '0-mcp[gen-mysql]' # + generator for MySQL $ pip install '0-mcp[gen-postgres]' # + generator for Postgres
01 — Why this exists

It started as a Django framework. The MCP server fell out of it.

Two years ago I got tired of writing the same Django REST API for the tenth time — DRF, Ninja, FastAPI, all powerful, all the same boilerplate. So I wrote a small framework for myself: one class, set some attributes, get the endpoints. I called it easyapi.

When MCP showed up and every project I had needed an agent surface, I expected to write a second codebase. Instead the MCP server fell out of the same engine in a weekend — auth was already there, rate limit was already there, the field whitelists were already there. Only the wire format changed.

REST is mostly a solved problem now. The new pain is MCP — most teams are rebuilding the same scaffolding. So I renamed the framework and put it on GitHub. 0-mcp — because that's how much work it should take.

— Stamatios Stamou Jr · github.com/ssjunior

02 — How to try it

Two ways in.

If you already have a Django app, two lines per resource is enough. If you have a database but no Django, the CLI reads your schema and writes the project for you. Either way you're running locally in a few minutes.

If you have Django

Two lines per resource.

Drop a class on top of any Django model. You get list/get/create/update/delete as MCP tools, and a REST endpoint with pagination, filters, and OpenAPI docs.

resources.py Python
from zeromcp import BaseResource from myapp.models import Space class SpaceResource(BaseResource): model = Space
→ list_space · get_space · create_space · update_space · delete_space
If you only have a database

One command.

Point the CLI at any MySQL or Postgres. Every table becomes a model, every model becomes an MCP tool, sensitive columns are auto-masked. Read-only by default.

terminal Shell
$ pip install '0-mcp[gen-mysql]' $ 0-mcp init # interactive — host, db, credentials # → ./mydb/  ./run.sh
→ Django project · MCP server · REST · OpenAPI · all running locally
03 — What's inside

The boring 90% I didn't want to write again.

001

One class for REST and MCP.

Same auth, same fields, same validation. The two surfaces can't drift because there's only one definition.

002

Async end-to-end.

Every handler is async. Async ORM, async Redis, async dispatch. No sync_to_async shims to remember.

003

Cache with namespace invalidation.

Editing row 5 doesn't drop the cache for row 7. Lists drop, unrelated rows stay warm. Took me a while to get this right.

004

Edge security middleware.

Scanner paths, bad user agents, 4xx flood detection. Real attack patterns I kept seeing in my own logs. One match, IP blocked for 24 hours.

005

Multi-tenant DB routing.

One call switches the connection for the request. My queries can't accidentally cross tenants because the connection isn't there.

006

Pydantic when I want it.

Set a schema on a resource, get validation. Skip it, fall back to Django field introspection. I adopt schemas one at a time.

007

OpenAPI 3.0.3.

Spec generated from the same resources, Scalar UI for the interactive view. The agent and the human see the same source of truth.

008

Ownership scoping.

One attribute (owner_field) and writes are scoped to the row's owner. The cheapest IDOR defense I know.

04 — Where this isn't for you

If any of these apply, pick something else.

I'd rather you bounce now than get stuck in a month. The framework is small and opinionated on purpose — that means it doesn't fit every shape of project.

— a

You don't have Redis available.

Sessions, cache, rate limit, abuse blocking — all rely on it. Non-negotiable.

— b

You need complex auth.

OAuth2 server, SAML, intricate permission matrices — DRF or a custom stack will fit better.

— c

Your endpoints are mostly RPC.

And you don't want them as MCP tools either. Different shape of problem, different tool.

— d

You don't want Django.

0-mcp wraps the Django ORM. The init command generates a Django project. If that's a dealbreaker, this isn't your tool.

— e

You want a big plugin ecosystem.

It's small on purpose. The whole point is that there isn't much of it.

0-mcp · MIT License · Stamatios Stamou Jr