AI agent editing for Django sites with MCP

Problem

AI agents such as Claude Code write and edit content well, but a Django site gives them no safe way in. The admin is built for people, building a custom API for every site is repeated work, and exposing models directly would let an agent change or delete anything.

Approach

django-agent-content: the Django app

Sites register what agents may edit in an agent_resources.py file, the way models are registered with the admin: which fields are writable or read-only, which actions exist (such as publishing) and which rules apply. The app builds a JSON API at /api/agent/ from those registrations. Every request needs an API key that acts as a Django user, so the site’s own permissions decide what it can do, and every change is recorded in the admin’s history. Saves go through Django forms and the model’s save(), so validation matches the admin.

agent-content-mcp: the MCP server

The MCP server runs on the user’s machine, reads the API’s description of itself at startup and generates its tools from it: a site with posts and a publish action gets list_posts, update_post and publish_post without any site-specific code. It installs with one command, uvx agent-content-mcp.

Key decisions

1. Explicit registration instead of exposing every model

   Why

   Nothing is reachable until a developer lists it, so private fields such as emails or staff flags can't leak.

   Trade-off

   Each site writes a small agent_resources.py file; a scaffold command generates the starting point.

2. Its own API keys instead of Django REST Framework tokens

   Why

   Keys are stored only as hashes, can expire, can be revoked one by one and show when they were last used.

   Trade-off

   Not a drop-in for sites that already authenticate with DRF.

3. Tools generated from the API description

   Why

   One MCP server works for any site, and the models' help texts become the documentation agents read.

   Trade-off

   Tool descriptions are only as clear as the site's help texts.

4. Drafts on create, slugs locked once published, no deletes

   Why

   An agent can't publish by accident, break published links or remove content.

   Trade-off

   Publishing stays a separate, explicit tool, and deleting stays a manual step in the admin.

5. Two packages connected only over HTTP

   Why

   The Django app ships no MCP code and the MCP server no Django code, so each can be used on its own.

   Trade-off

   Two releases to keep in step, checked with an API version number.

Result

Both packages are open source under the MIT licence and published on PyPI. The Django app is tested on Python 3.10 to 3.13 with Django 4.2 and 5.2, and this site uses both to manage its posts, projects and pages.