Skip to main content

easyapi

A framework I built for myself. It gives you a production MCP server and a REST API on top of Django models, sharing the same auth, rate limit, and tenant routing. REST and MCP each get a dedicated, well-shaped surface — they're no longer welded together. If you don't have Django, easyapi init reads a MySQL or Postgres schema and generates the whole project.

I run it in six of my own products. Sharing it because I'd like help making it better — issues, PRs, and "this broke for me" reports are all welcome.

Install

pip install easyapi-django                   # framework only
pip install 'easyapi-django[gen-mysql]'      # + generator for MySQL
pip install 'easyapi-django[gen-postgres]'   # + generator for Postgres

The PyPI distribution is easyapi-django. Imports use from easyapi import .... The CLI is easyapi.


What it looks like

REST resources are one class. MCP toolsets are another. They share auth, rate limiting and tenant routing through a common CoreResource base.

RESTBaseResource exposes a Django model as a CRUD endpoint:

from easyapi import BaseResource
from myapp.models import Space

class SpaceResource(BaseResource):
    model = Space

That class gives you:

  • REST endpoints (GET, POST, PATCH, DELETE) with pagination, filters, search, ordering.
  • OpenAPI 3.0.3 spec at /openapi.json and an interactive docs page at /docs.
  • Async dispatch, session + API-key + Bearer auth, per-IP rate limit, scanner blocking, multi-tenant DB routing.

MCPTools collects intent-named methods into an MCP tool registry. Type hints become JSON Schema (Draft 2020-12); docstrings become tool descriptions for the agent:

from typing import Literal
from pydantic import BaseModel
from easyapi import Tools, tool

class OrderOut(BaseModel):
    id: int
    status: str

class Orders(Tools):
    scope = "orders:read"

    async def find(
        self,
        status: Literal["open", "closed"] | None = None,
        limit: int = 50,
    ) -> list[OrderOut]:
        """List the caller's orders, optionally filtered by status."""
        qs = Order.objects.filter(owner_id=self.user_id)
        if status:
            qs = qs.filter(status=status)
        return [OrderOut.from_orm(o) async for o in qs[:limit]]

    @tool(scope="orders:write", destructive=True, rate_limit="10/m")
    async def cancel(self, order_id: int, reason: str) -> OrderOut:
        """Cancel an order and refund the original payment method."""
        order = await Order.objects.aget(pk=order_id)
        await order.cancel(reason)
        return OrderOut.from_orm(order)

Tools surface as <namespace>_<method>orders_find, orders_cancel. The framework follows the MCP client name regex ^[a-zA-Z0-9_-]{1,64}$ (dots aren't accepted by Claude.ai). The namespace defaults to the lower-cased class name, trimmed of a trailing tools (so OrdersToolsorders); override via namespace = '...' on the Toolset.

Wire both surfaces in urls.py:

from easyapi import get_routes

urlpatterns = get_routes(
    endpoints={r'orders(.*)$': OrderResource},
    toolsets=[Orders, Billing],
)

You get /orders… for REST, /mcp for JSON-RPC, /openapi.json, /docs, /mcp/tools (browseable) and /mcp/tools.json (machine-readable).

If you don't have Django yet:

easyapi init

The CLI prompts for host, db, credentials. About ten seconds later you have a working Django project — every table is a model with a REST resource. Sensitive columns (password, token, api_key) are auto-masked. Read-only by default. Pass --writable when you mean it. Write your MCP tools as Tools subclasses on top of the generated models.


Why it exists

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 cleaned up easyapi and put it on GitHub — same engine, now with a first-class MCP surface.


What you get

REST (BaseResource)

  • Async CRUD on Django models with pagination, filters, search, ordering.
  • OpenAPI 3.0.3 spec + Scalar UI.
  • Cache with namespace invalidation. Writes don't blow away unrelated rows.
  • Ownership scoping. One attribute (owner_field = 'owner_id') restricts every CRUD operation to rows owned by the authenticated user — the cheapest IDOR defense I know.

MCP (Tools + MCPServer)

  • Intent-named tools: each public method is a tool; _underscore methods stay private. Helpers that must stay public-but-non-tool go in excluded_methods = (...).
  • JSON Schema (Draft 2020-12) generated from type hints; raw schema escape hatch when you need it (@tool(input_schema={...})).
  • Docstrings become tool descriptions for the agent — the full docstring is published, not just the first line.
  • MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) via @tool(...). Read-scoped tools get readOnlyHint + idempotentHint automatically; override per-method when needed.
  • Per-tool scope and rate_limit ('10/m' shorthand or {'limit': N, 'window': seconds}). tools/list filters by the caller's OAuth scope so an agent only sees what it can call.
  • Class-level default_output_schema (set to False when methods return free-shape dict so the agent isn't misled by an auto-derived loose schema).
  • Pinned envelope: {tool, code, data} on success; {tool, code, message, ...} on error. Error codes are stable strings: OK, VALIDATION_ERROR, NOT_FOUND, FORBIDDEN, INSUFFICIENT_SCOPE, RATE_LIMITED, METHOD_NOT_ALLOWED, INTERNAL.
  • before_call / after_call hooks for audit and membership preloading.
  • MCPTestClient drives the registry in-process — unit tests don't need HTTP.

Shared (CoreResource)

  • Bearer + X-Api-Key + session-cookie auth.
  • Per-IP rate limit, scanner blocking, 4xx flood detection.
  • Multi-tenant DB routing. One call switches the connection for the request.
  • Sliding session TTLs via Redis GETEX. Configure with SESSION_TTL (default 1800s) and API_SESSION_TTL (default 300s).
  • Sensitive-field scrubbing (password, api_key, token baseline plus your additions) — applied on both REST and MCP responses.
  • Global read-only switch (EASYAPI = {'READ_ONLY': True}) rejects every non-GET request with 405.
  • Async end-to-end. Async ORM, async Redis, async dispatch.

Full docs and reference: https://github.com/ssjunior/easyapi-django


Connecting an agent

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "myapp": {
      "command": "python",
      "args": ["manage.py", "mcp_serve", "myapp.mcp.toolsets"],
      "cwd": "/path/to/your/project",
      "env": {
        "DJANGO_SETTINGS_MODULE": "myapp.settings"
      }
    }
  }
}

myapp.mcp.toolsets is a module-level sequence of Tools subclasses, e.g. toolsets = [Orders, Billing]. Restart Claude Desktop. The agent now sees every tool you declared.

For HTTP-based agents (Cursor, custom copilots, anything else that speaks JSON-RPC over POST), the same tools live at POST /mcp. Auth is whatever you've wired into your BaseResource stack — Bearer, X-Api-Key, or session cookie all work; per-tool scopes filter tools/list automatically.

curl -X POST http://localhost:8000/mcp \
  -H 'Content-Type: application/json' \
  -H "X-Api-Key: $TOKEN" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

When this isn't the right tool

I'd rather you bounce now than get stuck a month in.

  • No Redis available. Sessions, cache, rate limit and abuse blocking all rely on it. Redis 6.2+ (uses GETEX for sliding session TTLs). Non-negotiable.
  • You need complex auth. OAuth2 server, SAML, intricate permission matrices — DRF or a custom stack will fit better.
  • Your endpoints are mostly RPC, not CRUD. And you don't want them as MCP tools either.
  • You don't want Django. easyapi wraps the Django ORM. The init command generates a Django project. If that's a dealbreaker, this isn't your tool.
  • You want a big plugin ecosystem. It's small on purpose.

Hardening before you ship

Defaults are demo-friendly. Production deployments should:

  • Cookie auth. Set at least one of ENFORCE_TOKEN = True (HMAC anti-replay on state-changing requests) or ALLOWED_ORIGINS = [...] (Origin allowlist). Without either, the framework logs a startup warning — there is no built-in CSRF defense for POST/PATCH/DELETE.
  • Per-resource ownership. Set owner_field = 'owner_id' on resources where rows belong to a single user — restricts every CRUD operation to the row's owner. POST always forces owner_id to the caller (override with allow_owner_override = True for admin paths).
  • Authenticated cache. If you turn on cache = True for an authenticated resource, set session_cache = True or cache_scope_fields = (...) — otherwise responses can leak across users. The framework warns at runtime when it detects this combination.
  • Tune session TTLs. SESSION_TTL (cookies, default 1800s) and API_SESSION_TTL (api-key cache, default 300s) both slide on use. Pick numbers that match your security/UX trade-off.
  • Never ship DEBUG = True. Under DEBUG, edge security (scanner blocking, 4xx flood detection), rate limiting, credential-path defense and abuse blocking are all bypassed for dev ergonomics. The framework logs a loud startup warning when the bypass is active. To decouple from DEBUG — e.g. a staging box mirroring production — set EASYAPI = {'SECURITY_BYPASS': False} to force protections on (or True to bypass without DEBUG).
  • Trust your proxies explicitly. IP-based rate limits and abuse blocking key on the client IP. X-Forwarded-For / X-Real-IP are only honored when REMOTE_ADDR is in TRUSTED_PROXIES = ['10.0.0.0/8', ...]; otherwise REMOTE_ADDR wins. Leave it unset behind a proxy and every request looks like it comes from the proxy.
  • /metrics is opt-in. get_routes doesn't mount it unless you pass metrics_view=Metrics (the generic, unscoped resource — from easyapi import Metrics) or a custom row-scoped subclass. Once mounted, bound which models it can query: set METRICS_MODELS = ['app_Model', ...] to allowlist them. References to credential-named columns (in filters, groups, order or calc) are always rejected regardless — the per-resource escape hatch does not reach /metrics.
  • Bound the metrics fields, per model. METRICS_MODELS only gates which models — every non-credential field on an allowed model is still fair game for /metrics (filter, group, order, calc), including arbitrary FK traversal. Set METRICS_FIELDS = {'app_Model': ['status', 'owner__name', ...]} to also allowlist which field paths, per model. Unlike REST's filter_fields (root-segment match), this checks the full __-joined path — 'owner' in the list does not imply 'owner__anything' is allowed. filter_by references tolerate one trailing Django lookup (owner__name__icontains matches an allowed owner__name) since those reach Q(**kwargs) directly; calc/group_by/order/additional_fields/conditions don't take lookups and are matched literally. A model absent from the dict, or the setting left unset, stays unrestricted — opt-in, same as METRICS_MODELS. If you already maintain a bi_fields/related_fields map for a frontend field picker, easyapi.util.flatten_include_fields(model, bag) turns that same data into the flat path list this setting expects, so there's one source of truth instead of two.
  • Keep the escape hatch narrow. Columns whose names look like credentials (password, api_key, token, otp, secret, …) are masked as '*********' on every response, on top of whatever sensitive_fields lists. When the heuristic catches a false positive, opt it out per surface: edit_allow_sensitive_fields = ['token_count'] returns it verbatim on GET /resource/<id>/ while LIST still masks it. list_allow_sensitive_fields does the same for LIST, where every row carries the value — reach for the detail-only form first.
  • OAuth clients are public by default. MCP clients (Claude.ai, ChatGPT, ...) authenticate with PKCE — list them under EASYAPI['OAUTH_CLIENTS'] with no client_secret. A client becomes confidential only with an explicit secret; /register never hands out a confidential secret (provision those out of band).

Help wanted

If you try it and something breaks, please tell me. The kinds of help that make this better:

  • Bug reports. Open an issue with what you tried and what happened. Including the Python/Django version helps.
  • PRs. Small ones welcome. For larger changes, open an issue first so we can talk through the shape.
  • "This is confusing" feedback on the docs. The doc site needs more eyes.
  • Sharing how you use it. I'm curious what shapes of projects this actually lands in.

There's no CLA, no contributor matrix, no roadmap voting. Just open an issue and we figure it out.


Project

  • Author — Stamatios Stamou Jr
  • License — MIT
  • Python — 3.10+
  • Django — 5.0+
  • Repo — github.com/ssjunior/easyapi-django

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

easyapi_django-1.3.2.tar.gz (153.7 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

easyapi_django-1.3.2-py3-none-any.whl (178.0 kB view details)

Uploaded Python 3

File details

Details for the file easyapi_django-1.3.2.tar.gz.

File metadata

  • Download URL: easyapi_django-1.3.2.tar.gz
  • Upload date:
  • Size: 153.7 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.1.0 CPython/3.12.1

File hashes

Hashes for easyapi_django-1.3.2.tar.gz
Algorithm Hash digest
SHA256 3522fd89fc81d3312b0568d5d0bec41ae47ee687a33f320ab30daee09a8dba02
MD5 58aa3d212710f84a0e84193a051845fe
BLAKE2b-256 2f342bb8b18e4858f289fba7fc823c755151b29cd794d47523e8925d4fb4b936

See more details on using hashes here.

File details

Details for the file easyapi_django-1.3.2-py3-none-any.whl.

File metadata

  • Download URL: easyapi_django-1.3.2-py3-none-any.whl
  • Upload date:
  • Size: 178.0 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/6.1.0 CPython/3.12.1

File hashes

Hashes for easyapi_django-1.3.2-py3-none-any.whl
Algorithm Hash digest
SHA256 d01f54cfc9e80966a1f91c7fc04a627cc77af023e12f48f367acc01f594dab4a
MD5 a2ef9b5729e4e243a1a16dadf344d3c1
BLAKE2b-256 970e2ada49012ac5fdf3eb2a558ffcf000610fc9745f6ae24a927f3a373af780

See more details on using hashes here.

Release history Release notifications | RSS feed

1.8.3

2 files

1.8.2

2 files

1.8.1

2 files

1.8.0

2 files

1.7.0

2 files

1.5.1

2 files

1.5.0

2 files

1.4.0

2 files

This release

1.3.2 This release

2 files

1.3.1

2 files

1.3.0

2 files

1.2.2

2 files

1.2.1

2 files

1.2.0

2 files

1.1.7

2 files

1.1.6

2 files

1.1.5

2 files

1.1.4

2 files

1.1.3

2 files

1.1.2

2 files

1.1.1

2 files

1.1

2 files

1.0.1

2 files

1.0.0

2 files

0.37

2 files

0.36

2 files

0.35

2 files

0.34

2 files

0.33

2 files

0.32

2 files

0.31

2 files

0.30

2 files

0.25

2 files

0.24

2 files

0.23

2 files

0.22

2 files

0.21

2 files

0.2

2 files

0.1.26

2 files

0.1.25

2 files

0.1.24

2 files

0.1.23

2 files

0.1.22

2 files

0.1.21

2 files

0.1.20

2 files

0.1.19

2 files

0.1.18

2 files

0.1.17

2 files

0.1.16

2 files

0.1.15

2 files

0.1.14

2 files

0.1.13

2 files

0.1.11

2 files

0.1.10

2 files

0.1.9

2 files

0.1.8

2 files

0.1.7

2 files

0.1.6

2 files

0.1.5

2 files

0.1.4

2 files

0.1.3

2 files

0.1.2

2 files

0.1.1

2 files

0.1.0

2 files

0.0.99

2 files

0.0.98

2 files

0.0.97

2 files

0.0.96

2 files

0.0.95

2 files

0.0.94

2 files

0.0.92

2 files

0.0.91

2 files

0.0.90

2 files

0.0.89

2 files

0.0.88

2 files

0.0.87

2 files

0.0.86

2 files

0.0.85

2 files

0.0.84

2 files

0.0.83

2 files

0.0.82

2 files

0.0.81

2 files

0.0.80

2 files

0.0.79

2 files

0.0.78

2 files

0.0.77

2 files

0.0.75

2 files

0.0.74

2 files

0.0.73

2 files

0.0.72

2 files

0.0.71

2 files

0.0.70

2 files

0.0.69

2 files

0.0.68

2 files

0.0.67

2 files

0.0.66

2 files

0.0.65

2 files

0.0.64

2 files

0.0.63

2 files

0.0.62

2 files

0.0.60

2 files

0.0.58

2 files

0.0.57

2 files

0.0.56

2 files

0.0.55

2 files

0.0.54

2 files

0.0.53

2 files

0.0.52

2 files

0.0.51

2 files

0.0.50

2 files

0.0.49

2 files

0.0.48

2 files

0.0.47

2 files

0.0.46

2 files

0.0.45

2 files

0.0.44

2 files

0.0.43

2 files

0.0.42

2 files

0.0.41

2 files

0.0.40

2 files

0.0.39

2 files

0.0.38

2 files

0.0.37

2 files

0.0.36

2 files

0.0.35

2 files

0.0.34

2 files

0.0.33

2 files

0.0.32

2 files

0.0.31

2 files

0.0.30

2 files

0.0.29

2 files

0.0.28

2 files

0.0.27

2 files

0.0.26

2 files

0.0.25

2 files

0.0.24

2 files

0.0.23

2 files

0.0.22

2 files

0.0.21

2 files

0.0.20

2 files

0.0.19

2 files

0.0.18

2 files

0.0.17

2 files

0.0.16

2 files

0.0.15

2 files

0.0.14

2 files

0.0.13

2 files

0.0.12

2 files

0.0.11

2 files

0.0.10

2 files

0.0.9

2 files

0.0.8

2 files

0.0.7

2 files

0.0.6

2 files

0.0.5

2 files

0.0.4

2 files

0.0.3

2 files

0.0.2

1 file

0.0.1

2 files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page