Fix DRF Integration Body Processing and API Failure Issues

[zacharypodbela]

Summary

This PR fixes critical bugs in the Django REST Framework integration and adopts a cleaner architectural approach using composition over method patching.

Bugs Fixed

1. Body Parameter Mapping Issue

• Github Issue Link: Closes When using DRF decorators, tool schema provided by MCP Server does not match what DRF views can actually process #39
• Problem: MCP tool calls made with data nested inside a body property (e.g., {"body": {"title": "...", "content": "..."}}) were not being properly extracted for DRF serializers
• Symptom: DRF validation errors showing required fields as missing, even though they were present in the MCP call
• Root Cause: The request initialization flow was returning the original MCP JSON-RPC request instead of the fabricated request containing the extracted body data
• Fix: Proper data flow from MCP body parameters to DRF serializer data

2. Global ViewSet Patching Breaking Normal HTTP Requests

• Github Issue Link: Closes drf_publish_list_mcp_tool() breaks GET requests to DRF ListAPIView #32
• Problem: The initialize_request method was being globally patched on ViewSet classes, affecting ALL requests to those ViewSets, including normal API requests
• Symptom: Normal HTTP API requests (e.g., curl localhost:8000/posts/) failed with AttributeError: 'WSGIRequest' object has no attribute 'original_request'
• Root Cause: Method patching modified the class permanently, expecting MCP-specific request attributes on normal Django requests
• Fix: MCP requests conform to the same interface expectations as normal API requests and patching has been removed all together

Technical Strategy

Instead of trying to bypass or hack DRF's request creation, we pre-process the MCP request into exactly what DRF expects (a simple Django HttpRequest) and then let DRF run its full lifecycle using its intended mechanisms.

The benefits of this approach are:

1. Let DRF's unmodified initialize_request do its job naturally
2. DRF creates a proper rest_framework.request.Request with all the bells and whistles
3. Full DRF lifecycle runs: parsers, authentication, permissions, etc.

The potential drawbacks are:

1. We are using a Factory from DRF's testing library, which is probably not intended to be used for runtime purposes. In future version of DRF this may break (as the factory is likely to be extended to suit new testing needs).

Demo / Testing

Here are screenshots of my really simple Blog Post app (see code here) working with Claude Desktop:

Here's my really simple Blog Post app normal API calls working:

All tests in the bird_counter example app pass:

[omarbenhamid]

@Artui this PR proposes a clean way as it seems to manage the request, but removes part of the logic you coded. Can you please confirm that it does not break your use case ?

[Artui]

@Artui this PR proposes a clean way as it seems to manage the request, but removes part of the logic you coded. Can you please confirm that it does not break your use case ?

Yeah it will

[Artui]

@Artui this PR proposes a clean way as it seems to manage the request, but removes part of the logic you coded. Can you please confirm that it does not break your use case ?

But I can keep using the older version for now

[zacharypodbela]

@Artui what use case would this break? If you share more info I can try and figure out a solution that continues to support it, while fixing the 2 issues.

[omarbenhamid]

Well to give you an opinion on the topic :

• There two requests that live in parallel : the Django Request made by the MCP Client to the MCP Server, and the "Fake" DRF request which is transmitted with the view. The two have to be isolated and that's the reason why the DRF Request Wrapper exists: to fake a request to DRF without giving access to the MCP Request from client to server.

I don't have enough expertise on DRF internal to judge but I noticed that many issues are solved by giving somehow access to the original request, so maybe we should go this way. I appreciate about this MR that it uses APIRequestFactory which is test class, and that's an issue, but it is maintained by DRF team as DRF evolves and then keep request preparation right so I would tend to merge it.

@Artui

But I can keep using the older version for now
We should try not to accept regression, so if you have time to give it a try and provide some stacktrace or more insight to make this more robust, that would be perfect.

[Artui]

@Artui what use case would this break? If you share more info I can try and figure out a solution that continues to support it, while fixing the 2 issues.

I was attempting to fix the issue of having some arbitrary metadata fields on a django request object passed into MCP tools. Our views depend on some request.<field_name> properties being there, but because of how the tool wrapper is built - this call here actually will "reset" the WSGI request that is passed into MCP view

Here's a simplistic diagram that explains the issue

[zacharypodbela]

Ah that makes sense.

In your diagram you said "without data from middleware" -- Can you share more details on what data the middleware adds when an API call comes in that is missing when the Request is passed in via the Tool flow?

[ubongpr7]

Please i will like to ask, i get an error saying that viewset does not have attribute 'action' when i publishish and try the viewsets endpoint with my agent, again what is the fix for the missing have not been able to see that here. Is it part of a new release?

[omarbenhamid]

@Artui if we keep the request.original_request (I would prefer to rename it request.mcp_request) it would allow you to upgrade right ?

[Artui]

@Artui if we keep the request.original_request (I would prefer to rename it request.mcp_request) it would allow you to upgrade right ?

Yeah

[omarbenhamid]

@zacharypodbela very important PR as it solves in a nicer way a longering issue with the request object.
Would you please apply the suggested changes for backward compatiblity if you still have time on the topic ? If you can't I can do.

[omarbenhamid]

for compatibility of specific use cases that need for example communication between middleware and tools please add :

request.mcp_request = mcp_request
request.original_request = mcp_request  # For backward compatiblity

[omarbenhamid]

Add here :

warnings.warn("request.original_request is deprecated, and will be removed in future releases")

[aldegoeij]

#32 (comment)

PR confirmed working

[dmugtasimov]

An alternative approach that does not involve using rest_framework.test.APIRequestFactory:

import functools
import json
from io import BytesIO

import mcp_server.djangomcp as djangomcp
from django.http import HttpRequest


class CustomDRFRequestWrapper(HttpRequest):
    def __init__(self, mcp_server, mcp_request, method, body_json=None, id=None):
        super().__init__()
        self._original_django_http_request = original_django_http_request = mcp_request._request
        self.method = method
        self.content_type = 'application/json'
        serialized_body = b'' if body_json is None else json.dumps(body_json).encode('utf-8')
        self.META = getattr(original_django_http_request, 'META', {})| {
            'CONTENT_TYPE': 'application/json',
            'HTTP_ACCEPT': 'application/json',
            'CONTENT_LENGTH': len(serialized_body),
        }
        self._stream = BytesIO(serialized_body)
        self._read_started = False
        self.user = mcp_request.user
        self.session = mcp_request.session
        self.path = f'/_djangomcpserver/{mcp_server.name}'
        if id is not None:
            self.path = f'{self.path}/{id}'

    def __getattr__(self, name):
        return getattr(self._original_django_http_request, name)

def base_api_view_caller_tool_init(self, view_class, **kwargs):
    self.view = view_class.as_view(**kwargs)


djangomcp._DRFRequestWrapper = CustomDRFRequestWrapper
djangomcp.BaseAPIViewCallerTool.__init__ = functools.update_wrapper(
    base_api_view_caller_tool_init, djangomcp.BaseAPIViewCallerTool.__init__
)