I spent the long weekend pushing Logic Apps MCP server capabilities further than I had before — and hit two bugs worth documenting. Both are filed. If you're building in this space, save yourself the debugging time.
Context
If you've been following along, the MCP server and BODMAS Agent are covered in the previous posts. This post is just about what broke when I wired them together.
Bug 1 — Intermittent duplicate key error at tool registration
What happens
The Agent Loop fails with a BadRequest before making a single MCP call:
HTTP request failed: 'An item with the same key has already been added. Key: {tool_name}'.
Both the tool names and the MCP server names are unique in the workflow definition — no duplicates anywhere in the JSON.
What makes it particularly frustrating to diagnose
It is intermittent. Some runs fail, others succeed with identical configuration and identical input. No changes between a failing and a succeeding run — same workflow, same expression, same everything.
Load test
I ran three test patterns across 60 total requests — all using expressions covering power, square root, and division.
| Test | Requests | Succeeded | Failed | Failure Rate |
|---|---|---|---|---|
| Fully parallel | 30 | 17 | 13 | ~43% |
| Pairs of 2 (10s gap) | 20 | 14 | 6 | ~30% |
| Sequential (15s gap) | 10 | 7 | 3 | ~30% |
| Total | 60 | 38 | 22 | ~37% |
Failure rate drops when concurrency is reduced but never goes away — even fully sequential calls at 15-second spacing still hit ~30%.
View from Dev Tools:
Resubmitting the failed runs from the portal confirms the intermittent nature — the same expression that failed goes through successfully after one or more resubmits, with no changes to the workflow or inputs.
What you can't do
The Agent action has a default retry policy, but it does not help here. A BadRequest (400) is not treated as a transient error — the retry policy targets server-side failures (5xx), not client errors. So even with retries configured, the duplicate key error causes an immediate terminal failure. There is no clean in-workflow workaround.
Bug 2 — MCP Connector does not support OAuth
What happens
Both the MCP server and the MCP client are Logic Apps Standard. When OAuth is configured on the MCP server side, the workflow doesn't trigger at all — it never reaches the Logic App. The connection gets corrupted at design time with the OAuth setup, and no run is created.
Tools don't load but you can save the workflow.

You get a 502 bad gateway error when you push a request.

The same endpoint called directly from Postman with a valid bearer token works fine.
Why it matters
To get the Agent Loop working, the MCP server has to run with either anonymous authentication or key-based authentication. OAuth simply does not work with the built-in MCP client connector.
Current state
Both issues are filed on the Logic Apps GitHub repo:
Agent Loop: "An item with the same key has already been added" when using McpClientTool
The issue covers both bugs with full workflow JSON, reproduction steps, and screenshots. If you've hit either of these, add a reaction or comment — the more signal on the issue, the better.
What works in the meantime
- Set
"type": "anonymous"in theMcpServerEndpointsauthentication block inhost.json— removes the OAuth blocker for dev and demo use - Accept the intermittent failure rate on the Agent Loop and re-trigger manually when it hits — not a fix, but the success rate is high enough to keep building and testing
Both issues are filed. If you hit either of them, the GitHub issue is the right place to add signal.



Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.