APIM REST API exposed as MCP sends raw string body instead of JSON object for POST operation

Also .. It was working earlier now its not working

Hi @K S, Aptha ,

It looks like you’re running into a side‐effect of how APIM generates MCP “tools” based on your API’s request schema. When the tool’s input schema is a primitive (e.g. a single string), the MCP client will send just that raw string, and APIM will forward it straight to your backend, so you end up losing the original { "query": "…" } envelope. That’s expected today APIM infers your tool’s input shape directly from the OpenAPI/request-body schema.

Here’s how you can fix or work around it:

1. Make your request-body schema an object, not a primitive • In your API’s OpenAPI (or in APIM’s “Design” tab), define the body as:

   
        requestBody:
   
          content:
   
            application/json:
   
              schema:
   
                type: object
   
                properties:
   
                  query:
   
                    type: string
   
                required:
   
                  - query
   
   

   • Re-export the MCP server. Now the generated tool input will be an object, and the MCP client will send { "query": "sample search text" }.
2. If you can’t change the schema, use an inbound policy on the underlying REST API to rewrap the string • On your API operation in APIM, add something like:

   
        <inbound>
   
          <set-body>@{
   
            var text = context.Request.Body.As<string>(preserveContent: true);
   
            return Newtonsoft.Json.JsonConvert.SerializeObject(new { query = text });
   
          }</set-body>
   
          <forward-request />
   
        </inbound>
   
   

   • This will take the raw string from the MCP tool, wrap it in { "query": … }, and forward it.
3. Generated input schema: • Right now APIM sees a single string property and makes your tool input a primitive string. That’s why your backend only sees "sample search text". • If you switch to an object schema, the generated tool input becomes that object.
4. Policy support: • You can use <set-body> (and other transformation policies) on the API operation level to reshape the request. • MCP-server–level policies apply globally (rate-limits, auth, etc.) but won’t change the per-tool request shape.
5. Known limitation/regression? • This is a by-design behavior today when your request schema is a primitive. It’s not documented as a bug, but you’ll hit it as long as your tool schema is “string” instead of an object.

Hope that helps!

@Pravallika KV
Thanks, that explanation helped.

One clarification: my REST API request body schema is already an object with a single required string property, not a primitive schema. The operation expects this shape:

{
	"query": "sample search text"
}

The REST API works correctly through direct calls and through the APIM Test console. The issue appeared only when the same REST operation was exposed as an MCP tool. In that path, APIM seemed to flatten the single-property object into a primitive MCP tool input and forwarded only the raw string to the backend.

We applied an operation-level inbound policy on the underlying REST API operation to detect raw string bodies and wrap them back into the expected JSON object. After restarting the MCP server/client, the MCP tool call started working.

So the current understanding is:

• Direct REST API behavior is fine.
• APIM REST-to-MCP generated tool appears to flatten a single-property JSON object into a primitive input.
• The workaround is to apply the request body rewrapping policy at the underlying REST API operation level, not at the MCP server policy level.
• MCP server-level policy affected the MCP endpoint itself and caused errors during MCP startup/handshake.

Could you please confirm whether this single-property object flattening is expected behavior for APIM REST-to-MCP? If yes, is the operation-level policy the recommended workaround, or is there a schema/design approach to force the generated MCP tool to preserve the original JSON object envelope?

@K S, Aptha , Yes, what you are observing is expected behavior in Azure API Management’s “Expose REST API as MCP server” feature. When a REST API operation’s request body is a single-property JSON object, APIM flattens it into a primitive input for the generated MCP tool. As I mentioned earlier, this is by design - APIM simplifies the MCP tool input when it detects that the object contains only one property.

Given this behavior:

• Applying an operation-level inbound policy on the underlying REST API operation to detect raw string bodies and wrap them back into the expected JSON object is the recommended and supported workaround.
• MCP server-level policies cannot reliably transform per-operation request bodies and may interfere with MCP server startup or handshake, as you observed.
• Currently, there is no schema/design approach that forces APIM to preserve the single-property JSON object in the generated MCP tool input without changing the object structure. A potential alternative would be to add an additional property or wrap the single property in another object, but this would require a change to your API contract.