Azure-Samples / Azure-Samples/azure-postgres-mcp-demo

MCP tool fails with “Always Approve” in Azure AI Foundry — array response format issue

Open
#7 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Bicep
Stars
7
Forks
8
PR merge metrics
No merged PRs in 30d

Description

## Bug: MCP tool fails with "Always Approve" in Azure AI Foundry — array response format issue

**Environment**
- Repo: `azure-postgres-mcp-demo`
- Upstream server: Azure MCP Server (`Azure.Mcp.Server`)
- Platform: Azure AI Foundry Agent (portal UI)

**Steps to reproduce**
1. Deploy the Azure Postgres MCP server following the README
2. Connect it to an Azure AI Foundry agent via the Catalog tool ("Azure Database for PostgreSQL")
3. Set the tool approval mode to **Always Approve** in the Foundry portal
4. Trigger the agent

**Expected behavior**
The agent executes MCP tool calls automatically without requiring human approval at each step.

**Actual behavior**
The agent run fails immediately with:
```
The requested operation required an element of type 'Object' but the target element has type 'Array'
```

**Root cause**
All tools in this MCP server return responses where the `results` field contains objects whose values are arrays, for example:
```json
{
"status": 200,
"results": {
"Tables": ["users", "sessions", "events"]
}
}
```
When approval mode is set to **Always Ask**, a human validates each call and Foundry passes the response as-is to the LLM — this works fine.

When approval mode is set to **Always Approve**, the Foundry workflow runtime tries to automatically bind the tool response into its internal state. It expects a flat JSON object at the top level but encounters arrays inside `results`, causing the deserialization to fail.

This is consistent with the known Foundry limitation reported here:
- https://learn.microsoft.com/en-us/answers/questions/5668414/automatic-tool-calls-in-my-foundry-workflow-keep-e
- https://learn.microsoft.com/en-us/answers/questions/5638933/ms-foundry-workflow-failing-to-invoke-agent-when-t

**Why this MCP specifically**
Other MCP servers (GitHub, Slack, etc.) return flat objects that Foundry can deserialize without issue. This server is the only one in my setup that uses arrays as values inside `results`, which is what triggers the bug.

**Workaround**
Using the Python SDK with `require_approval: "never"` passed explicitly in `tool_resources` at run creation bypasses the Foundry workflow runtime and works correctly — as shown in `client/agents_mcp_sample.py`.

```python
mcp_tool_resources = {
"mcp": [{
"server_label": mcp_server_label,
"require_approval": "never"
}]
}
run = agents_client.runs.create(
thread_id=thread.id,
agent_id=agent.id,
tool_resources=mcp_tool_resources
)
```

**Suggested fix**
Wrap array values inside `results` in a consistently named object key, so the response shape is always a fully flat JSON object. This would make the server compliant with the Foundry workflow runtime's schema expectations without breaking existing behavior.

Alternatively, this should be flagged in the README as a known limitation when using the Foundry portal UI.

Contributor guide

No contributing guide indexed for this repository

Research direction

Review the README deployment instructions and client/agents_mcp_sample.py, then reproduce the failure with Azure AI Foundry using Always Approve and compare it with the Python SDK workaround. Trace the tool response shape, especially array values under results. Done means the affected workflow no longer fails, or the README clearly documents the portal limitation if it is external to this server.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, python
Domain
api, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.