[Feature Request] Support Exposing Endpoints as MCP Services (Similar to fastapi_mcp)

[chaofanat]

Background & Use Case

As a long-time user of Django-Ninja, I deeply value the completeness of the Django ecosystem and its clear architecture, as well as the efficient API development experience that Django-Ninja provides. I am currently building a project with Django-Ninja and have a critical need: I want to expose API endpoints as MCP services (similar to how fastapi_mcp does for FastAPI), to integrate with agent-based systems and remote service protocols.

While FastAPI has existing support for such protocols, I prefer to stay within the Django ecosystem to leverage its mature features (middleware, ORM, admin panel, etc.) and avoid fragmenting my tech stack.

Feature Request

I propose adding native support in Django-Ninja to expose endpoints as MCP services.
Key requirements:

1. Dedicated Router/Decorator: Introduce a @mcp_router decorator or configuration to mark routes/controllers as MCP endpoints, separate from HTTP endpoints if needed.
2. Protocol Parsing: Support MCP-specific request/response parsing (message format, authentication, streaming, etc.), compatible with Django’s request lifecycle.
3. Asynchronous & Middleware Compatibility: Work with Django’s async views (if MCP supports async) and integrate seamlessly with existing middleware.

Reasons & Value

1. Tech Stack Consistency: Keep the project within the Django ecosystem, reducing maintenance costs from adopting additional frameworks.
2. Future-Proofing: With the rise of agent systems and distributed services, protocols like MCP (e.g., for remote procedure calls, multi-channel communication) are becoming essential. Supporting them will make Django-Ninja more competitive for modern use cases.
3. Developer Experience: The fastapi_mcp implementation proves this is feasible. Bringing this capability to Django-Ninja will benefit developers who prefer Django’s architecture but need MCP-compatible services.

Desired Outcome

• Documentation: Clear guides on how to define and configure MCP endpoints in the Django-Ninja docs.
• Examples: Sample code snippets for basic MCP endpoint definitions, authentication setup, and error handling.
• Coexistence: MCP services should work alongside existing HTTP endpoints without conflicts.

Thank you for considering this request! I believe it will make Django-Ninja more versatile for emerging service architectures.

Best regards,
chaofan

[vitalik]

@chaofanat that should be relatively easy (especially by coping major part from fastapi-mcp)

would like to volunteer to do something wit this like at least write documentation ?

[mikeedjones]

I took at pass at implementing a ninja version of fastapi-mcp https://github.com/mikeedjones/django-ninja-mcp

It was kinda straightforward but depends on #1388 and the LiveServerTestCase I implemented all hang as the sse transport threads blocked one-another.

EDIT: Got live_server tests passing by using a channels live server client.

[chaofanat]

I'm glad you noticed this feature request. I'd be happy to contribute to this project, such as writing documentation. However, I'm not a professional programmer and I'm not very familiar with the open source community participation process. I may need some time to learn about it. I can dedicate about one hour per day to work on this.
Regarding mikeedjones' django-ninja-mcp library, while it resembles fastapi-mcp, I don't think fastapi's approach to integrating with MCP is perfect. For instance, I don't understand why we need to declare URL endpoints again when creating MCP services. Isn't this something that Django or FastAPI frameworks have already handled? Additionally, Django supports multiple django-ninja endpoints, and I'm not sure if MCP services can be bound multiple times or if multiple MCP services can be declared?

[mikeedjones]

Its a fair criticism - internally fast-mcp (and now ninja-mcp) are making new rest calls using httpx to the original ninja endpoints as opposed to calling the ninja path operation functions directly. It is probably sub-optimal to make those calls directly because ninja expects those functions to be accessed restfully, but to do so requires the mounted MCP server to know where the Ninja endpoints are exposed.

You can mount as many MCP servers as you like with ninja-mcp - and mount them wherever you like. The NinjaMCP class ingests a NinjaAPI instance to build the suite of tools it wants to expose and the serves it wherever you choose to mount it. Or at least that's the idea - still need to add a lot of tests.

[mikeedjones]

It looks like MCP changed the protocol a little - modelcontextprotocol/python-sdk#573 looks significantly more robust. I'll take a look at updating my implementaiton.

[shfJP]

I don't understand why we need to declare URL endpoints again when creating MCP services. Isn't this something that Django or FastAPI frameworks have already handled?

Exposing too many tools to an LLM can create context issues. Instead, consider offering a few endpoints that combine multiple functions. Your API descriptions may be more suited for programmers than for LLMs. By presenting tools separately, you can better tailor the tool descriptions for LLM compatibility without altering the API endpoint descriptions.