frisian-mcp
OfficialExposes existing Django REST Framework ViewSets as MCP tools with auto-discovery, enabling AI agents to call list, retrieve, create, update, and delete operations on Django models.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@frisian-mcplist all customers in the database"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
frisian-mcp
The Django MCP gateway that discovers your API automatically.
frisian-mcp turns your existing Django REST Framework ViewSets into Model Context Protocol tools with zero boilerplate. Add the package, include one URL, and every ViewSet action becomes a callable MCP tool — name, description, and input schema derived from your serializers automatically.
Designed for token-efficient agent workflows. A 50-action Django app loads in 500–2,000 tokens of tools/list schema instead of the 15,000–25,000 conventional flat MCP would emit; a 60-device bulk-write response is 24 tokens instead of ~10,800 of full echo. Same surface, two orders of magnitude less context burned before the agent has done any reasoning. Full numbers in Token efficiency.
Version: 1.1.0 | License: Apache 2.0 | Python: 3.11+ | Django: 5.x
pip install frisian-mcpProject site: https://frisian-mcp.com/
A live MCP server is hosted at https://frisian-mcp.com/ for hands-on evaluation — point any MCP-compatible client at it to see the dispatcher pattern and lean envelope behavior against a real surface. The same site serves the project documentation through an MCP-consumable dispatcher, so coding agents (Claude Code, Codex, Gemini CLI, etc.) can connect to it directly and consume installation, configuration, and decorator reference material as part of their working context while integrating frisian-mcp into your own project.
At a glance
Feature | Details |
Auto-discovery | Walks URL patterns at startup; registers every ViewSet action as an MCP tool |
Zero boilerplate | Name, description, and input schema derived from DRF serializers automatically |
| One tool → many actions; built-in help mode; per-action validation |
| Explicit single-function tool registration for custom logic |
| Expose server-side content via |
Filter introspection |
|
Allowlist / denylist |
|
Dispatch groups |
|
Deferred discovery | URL scan fires on first request — captures late-loading plugin ViewSets |
OAuth 2.0 |
|
Static tokens |
|
Per-agent scoping |
|
Permission tiers |
|
Host-app scoping |
|
Tool middleware |
|
Rate limiting |
|
Pluggable backends | Custom discovery and invocation backends via dotted-path settings |
SSE support |
|
MCP | Streamable HTTP; |
Related MCP server: django-rest-framework-mcp
Token efficiency
The dispatcher pattern and the lean write envelope exist for one reason: agent context windows are finite, and the conventional MCP shape (one tool per ViewSet action; full serialized echo on every write) burns through that budget before the agent has done anything useful.
Measured numbers from real integrations:
Scenario | Default MCP shape | frisian-mcp | Reduction |
| ~15,000–25,000 tokens | 500–2,000 tokens with | ~95% |
| 1,737 flat tools | 15 dispatcher tools | tool surface reduced ~99% |
60-device bulk-create response | ~10,798 tokens (full echo) | 24 tokens (lean envelope) | 99.8% |
200-device bulk-create response | ~36,000 tokens | 24 tokens (constant) | 99.9% |
The bulk-write savings are constant regardless of batch size — the lean envelope is fixed-shape and the full response is reachable via the continuation token without re-running the write. The dispatcher reduction is opt-in through FRISIAN_MCP_DISPATCH_GROUPS (autodiscovery alone gives the conventional flat shape).
See The Token Problem, Dispatcher Pattern, and Write-Path Response Filtering for the design rationale and full measurements.
Requirements
Python 3.11+
Django 5.x
Django REST Framework 3.14+
Quickstart
1. Install and add to INSTALLED_APPS:
# settings.py
INSTALLED_APPS = [
...
"frisian_mcp",
]2. Include the gateway URL:
# urls.py
from django.urls import include, path
urlpatterns = [
...
path("mcp/", include("frisian_mcp.urls")),
]That's it. With auto-discovery enabled (the default), every DRF ViewSet in your URL tree is now an MCP tool.
# myapp/views.py — nothing changes here
class UserViewSet(viewsets.ModelViewSet):
queryset = User.objects.all()
serializer_class = UserSerializer
permission_classes = [IsAuthenticated]After startup, the gateway exposes users.list, users.retrieve, users.create, users.update, users.partial_update, and users.destroy — derived entirely from the ViewSet.
3. Generate a client config:
python manage.py mcp_config --token mytoken123{
"mcpServers": {
"frisian-mcp": {
"url": "http://localhost:8000/mcp/",
"transport": "http",
"headers": { "Authorization": "Bearer mytoken123" }
}
}
}Use --client to emit the format expected by a specific MCP client. Use --url and --name to override the server URL and key.
4. Verify the install:
python manage.py mcp_doctor # standard audit
python manage.py mcp_doctor --security # extended OAuth security auditWalks the configuration end-to-end and exits non-zero on errors. Run after every install, every config change, and as the first diagnostic step on any unexpected behaviour. See the mcp_doctor guide for the full check list.
Architecture overview
MCP Client
│ JSON-RPC 2.0 over HTTP POST
▼
┌──────────────────────────────────────────────────┐
│ McpView (DRF APIView) │
│ ├─ Authentication (FRISIAN_MCP_AUTHENTICATION_CLASSES) │
│ ├─ Permissions (FRISIAN_MCP_PERMISSION_CLASSES) │
│ └─ Method dispatch │
│ ├─ initialize / initialized / ping / help │
│ ├─ tools/list ──────────────── ToolRegistry │
│ ├─ tools/call ── ToolMiddleware ── Registry │
│ ├─ resources/list ───────── ResourceRegistry │
│ └─ resources/read ───────── ResourceRegistry │
└──────────────────────────────────────────────────┘
│
┌──────────────────┐ ┌─────────────────────────┐
│ ToolRegistry │ │ Auto-discovery │
│ (module-level │◄──│ (DRFSyncDiscovery) │
│ singleton) │ │ Walks URL patterns at │
│ │ │ AppConfig.ready() │
└──────────────────┘ └─────────────────────────┘
│
┌──────────────────────────────────────────────────┐
│ InvocationBackend (SyncInvocation by default) │
│ Builds synthetic DRF Request → calls ViewSet │
│ action → returns ToolResult │
└──────────────────────────────────────────────────┘Separation of discovery and invocation. Two pluggable backends — override either independently.
Registry is the source of truth.
@mcp_tool,@mcp_dispatcher, and auto-discovery all write to the sametool_registrysingleton.Tool errors are
isError: true, not JSON-RPC errors. Permission denials and handler exceptions returnisError: trueinside a normal HTTP 200 response — the session stays alive.Two enforcement points. Gateway-level permissions gate the entire
/mcp/surface. Tool-level tiers gate individualtools/callinvocations.
Dispatcher pattern
For teams building purpose-built agent tools, frisian-mcp ships the @mcp_dispatcher pattern: one MCP tool name routes to many actions internally.
from frisian_mcp import mcp_dispatcher, mcp_action
@mcp_dispatcher(name="tasks", description="Manage project tasks.")
class TasksDispatcher:
@mcp_action(name="create", description="Create a task.")
def create(self, request, params):
task = Task.objects.create(title=params["title"])
return {"id": task.pk}
@mcp_action(name="list", description="List tasks by status.")
def list(self, request, params):
return {"tasks": list(Task.objects.values("id", "title", "status"))}One tool in tools/list instead of many. Call with action="help" for a structured listing of available actions. Per-action JSON Schema validation runs before the method.
This is the pattern for agent-facing APIs where tool count matters and progressive disclosure beats a flat list.
For high-volume APIs, FRISIAN_MCP_DISPATCH_GROUPS can automatically bundle existing auto-discovered tools into dispatchers with no extra code.
Authentication and security
frisian-mcp delegates authentication to DRF — any DRF authentication class works out of the box via FRISIAN_MCP_AUTHENTICATION_CLASSES. Three ready-to-use contrib modules cover the most common cases:
Module | What it provides |
| HMAC-hashed static Bearer tokens for internal agents and service accounts |
| Full OAuth 2.0 — authorization code (PKCE) + client credentials; redirect URI allowlist |
| Per-credential tool allowlists; connections fail-closed when the credential is deactivated |
Gateway-level access is controlled by FRISIAN_MCP_PERMISSION_CLASSES. Tool-level access is controlled by permission tiers (read / read_write / admin) mapped via FRISIAN_MCP_TOKEN_TIER_MAP. Use FRISIAN_MCP_MAX_TIER to cap all callers on an endpoint regardless of their credential tier.
Hardened-by-default posture (1.0.x)
The defaults are oriented toward production safety rather than walk-up convenience:
Token and client-secret storage uses HMAC-SHA256 digests (
FRISIAN_MCP_HMAC_KEY). A leaked database row cannot be replayed directly — the raw secret is only ever shown once at creation time.OAuth dynamic client registration is closed by default (
FRISIAN_MCP_OAUTH_REGISTRATION_OPEN=False,FRISIAN_MCP_OAUTH_PKCE_AUTO_REGISTER=False,FRISIAN_MCP_OAUTH_AUTO_APPROVE=False). The operator pre-registers every OAuth client via the Django admin; anonymous walk-up registration is not possible without an explicit opt-in.The PKCE default permission tier is
read. Mis-configurations cannot accidentally hand out write or admin scopes on first connect.Permission-aware discovery (
FRISIAN_MCP_PERMISSION_AWARE_DISCOVERY=True) rebuilds dispatcher action enums per-request — a read-tier token sees onlylist/retrieveactions, write and admin actions are hidden fromtools/listrather than just blocked at execution..well-knowndiscovery metadata is gated byFRISIAN_MCP_OAUTH_PUBLIC_DISCOVERY. With it set toFalse, the OAuth metadata endpoints return parseable JSON 404s so discovery-first MCP clients fall back to their configured Bearer instead of being routed into a dead-end OAuth cascade.Authenticator chain ordering is no longer load-bearing for correctness — both
FrisianMcpTokenAuthenticationandOAuthTokenAuthenticationreturnNoneon lookup-miss so either order works. Tokens-first is the recommended convention for the WWW-Authenticate challenge shape (see docs/Getting Started/getting-started.md).SSE keepalive structure is documented, with a one-time runtime warning when the package detects it is running under a synchronous WSGI worker (which cannot scale SSE without starving the worker pool). The recommended deployment is an ASGI worker class (
uvicorn.workers.UvicornWorkeroruvicorndirectly).
Authorize-path hardening
The unauthenticated OAuth authorize path (AUTO_REGISTER) is a walk-up surface: request inputs describe what the caller wants, never what the caller is permitted to do. See ADR-009 for the design rationale and the security guide for the threat model and recommended deployment patterns.
Per-route permission tiers
FRISIAN_MCP_ROUTES mounts read, read_write, and admin surfaces on separate paths, each with its own tool allow/deny list and tier ceiling on a deny-all baseline. A tool denied on a route does not exist there — it is absent from discovery and invocation, not merely rejected at call time. Misconfigurations are caught at startup; a route that would serve a privileged surface anonymously refuses to boot. See ADR-010 for the model and its security rationale.
Full documentation
Full settings reference, auth configuration, decorator API, middleware, pluggable backends, security guide, and troubleshooting are in docs/.
For browsable docs, a live MCP server, and the agent-consumable docs dispatcher (point your coding agent at it directly), visit https://frisian-mcp.com/.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- Alicense-qualityDmaintenanceA Django MCP server that exposes tools and resources to AI agents using simple decorators, with auto-discovery, type safety, and custom authentication.Last updatedMIT
- Alicense-qualityDmaintenanceExposes Django REST Framework APIs as MCP tools, enabling natural language interactions with your data models such as CRUD operations and custom actions, with automatic schema generation from DRF serializers.Last updated52BSD 3-Clause
- Alicense-qualityCmaintenanceExposes Django REST Framework APIs as MCP tools for AI agents via the Model Context Protocol, with automatic discovery and security.Last updated1MIT
- Alicense-qualityDmaintenanceAutomatically exposes Django REST Framework endpoints as MCP tools with zero configuration, supporting multiple transports and authentication.Last updatedMIT
Related MCP Connectors
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Free public MCP for AI agents — 193 tools, 44 workflows. No API key.
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Frisian-MCP/frisian-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server