Exposing API as MCP Server in Azure API Manager is not passing POST body to API

Try removing the policy and simply log the full raw body (params.arguments) in your function.

This is the problem though ... NOTHING is coming, the request body is an empty string

[OpenApiOperation(operationId: "MCPEvalController", tags: new[] { "MCPEvalController" }, Summary = "Testing MCP through APIM", Visibility = OpenApiVisibilityType.Important)]
[OpenApiRequestBody("application/json", typeof(MCPRequest), Description = "MCP Request Body")]
[OpenApiResponseWithBody(statusCode: HttpStatusCode.OK, contentType: System.Net.Mime.MediaTypeNames.Application.Json, bodyType: typeof(MCPResponse), CustomHeaderType = typeof(OpenApiCustomResponseHeader), Summary = "OK", Description = "OK")]
[Function("MCPEvalController")]
public async Task<HttpResponseData> RunP([HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "Calculator")] HttpRequestData req)
{
   var logger = req.FunctionContext.GetLogger("HttpFunction");
   logger.LogInformation("MCPEvalController triggered.");
   string requestBody = await req.ReadAsStringAsync();
   logger.LogInformation($"Request Body: |{requestBody}|");

2025-07-10T10:22:59Z [Information] MCPEvalController triggered.
2025-07-10T10:22:59Z [Information] Request Body: ||

Ahh ... A breaktrhrough .. I was too fixated on the MCP policies and thought lets check the actual underlying API.

So I created a HEADER parameter which is a copy of the body content and my function is receiving this.

    <inbound>
        <base />
        <set-header name="mytest" exists-action="append">
            <value>@(context.Request.Body.As<String>())</value>
        </set-header>
    </inbound>

mytest: {"number2":7,"number1":3}

So, it appears that somewhere in my function is having issues

Hello Chris Hammond •,
Since your function correctly receives the body when passed as a header, this confirms that the issue is within the function’s body parsing logic, not the MCP or APIM policy.

Suggested Checks:

Make sure the function reads the body properly (e.g., using req.Body).

Ensure Content-Type is set to application/json.

If using model binding, verify the JSON matches the expected schema.

Hello Chris Hammond •,
Just following up to see if you had a chance to review my previous response and if you have any additional questions.

I have carried out some more testing but it is simply refusing to work. If I call the APIM endpoint for the Function App as a REST Api, it works absolutely fine, but if I call it through its MCP endpoint its not working.

Plus, now, POSTMAN cannot even Connect to the server, let alone making a request.

So, further developments.

If I put the <set-body>@(context.Request.Body.As<String>())</set-body> as part of the inbound policy of the MCP server, the whole thing breaks, cannot even connect to the server.

However, if I put it in the underlying API policy then everything starts working. Wahoo...

But, just because its working, I do not believe this is the solution because I don't want to go through every single API adding what is essentially a a = a statement. There must be something fundamentally wrong somewhere in the request chain.

Additionally, in the MCP Policy, I added the following to the inbound policy, but this is NOT passed on to the API

        <set-header name="myHeader" exists-action="override">
            <value>Hello</value>
        </set-header>

Hello Chris Hammond •,

Great work troubleshooting this — your findings make a lot of sense.

What’s happening is that when you add <set-body> to the MCP policy, it breaks because the MCP endpoint doesn’t directly forward the request like a normal API. It wraps the request in its own structure and handles it internally before calling your backend. So if you try to set or modify the body there, it can disrupt that process — which explains the connection issues and why Postman couldn’t reach it.

On the other hand, adding the same logic in the backend API’s policy works fine because that’s where the actual request gets sent to your Azure Function. That’s the right place to reshape the request before your function handles it.

Same goes for headers like myHeader — setting them in the MCP layer won’t automatically pass them through unless you explicitly forward them from the backend policy.

So, you’re right — while putting the logic in the backend works, it’s not ideal to do it for every single API manually. This points to a bigger structural gap in how MCP handles requests versus direct API calls.

So, you’re right — while putting the logic in the backend works, it’s not ideal to do it for every single API manually. This points to a bigger structural gap in how MCP handles requests versus direct API calls.

Exactly this ... So where do we go from here!

I wonder if Julia Kasper reads these ;)

Hello Chris Hammond •,
To avoid repeating logic in every API, you can use Policy Fragments in Azure API Management. These are reusable policy blocks that can be included across multiple APIs.

Reference documentation:

Policy Fragments Overview

Include Fragment Policy

Next Step:

Create a shared fragment (e.g., to unwrap params.arguments) and include it in your API policies using:

xml
Copy
<include-fragment fragment-id="McpBodyUnwrapper" />

Hello Chris Hammond •,

Just checking in to see if you've had a chance to review my previous response. Let me know if you have any additional questions.

Hi @Krishna Chowdary Paricharla

I've been in contact with the API Management Product Group and they have advised that this may be a bug in the system (yes, Julia's team :) )

"Thanks for reaching out. I believe the issue you are experiencing may be related to a bug with tool argument parsing which we have since resolved in our latest release version. "

They then listed the regions that have been updated unfortunately my specific region has yet to receive the update, so I am just waiting now. Once I have the updated version, I'll test again.

Thank you though for your diligent efforts to help me resolve the issue