Forum Discussion
Published agent from Foundry doesn't work at all in Teams and M365
- Jan 27, 2026
Thanks for the detailed follow-up, Alexey — these behaviors are confusing, but they are consistent with how Foundry agents currently integrate with Teams.
I’ll answer your questions one by one.
1) Agent responds in Teams, but MCP tool calls fail
This is a known limitation of Azure AI Foundry agents in Teams today.
Key points:
- Foundry Playground runs agents inside Azure, where MCP servers are reachable.
- Microsoft Teams / M365 Copilot runs the agent through the InfoConnect Agent runtime, which has strict network and execution constraints.
- MCP servers must be:
- Publicly reachable over HTTPS
- Respond within tight latency limits
- Not require interactive auth, VPN, or private network access
In practice:
- Many MCP servers (including AS/400-backed services) work fine in Playground
- The same MCP servers fail silently or error in Teams
This is why:
- Simple prompts work
- Tool calls consistently fail
At the moment, MCP support in Teams is limited and not parity with Playground. This is a platform gap, not a configuration issue on your side.
2) Only one Foundry agent identity appears, with “no permissions”
This is expected behavior.
Foundry creates one shared Teams app (InfoConnect Agent) per tenant, not one per agent.
What you’re seeing:
- Multiple Foundry agents → same underlying Teams app
- Teams Admin Center shows:
- “The app doesn’t have any permissions”
This message is misleading:
- It does not refer to Entra ID, RBAC, or Graph permissions
- Foundry agents do not expose per-agent permission manifests in Teams
- Permissions are evaluated at runtime by Foundry, not Teams
So:
- You won’t see multiple app entries
- You won’t see meaningful permission details in Teams Admin Center
- This is by design (for now)
3) Agent does not appear in “Add agents and bots” for channels
This is also expected.
Foundry agents currently:
- Do NOT behave like traditional Teams bots
- Cannot be added via:
- Channel → Add agents and bots
Instead, they can only be used via:
- Teams → Copilot → My agents
- 1:1 Copilot-style interaction
Channel, meeting, and group-chat scenarios are not supported yet for Foundry agents.
That’s why:
- You can see them under Copilot / Manage apps
- But not in channel bot pickers
Important clarification about “installing” the agent
There is no separate per-agent installation step today.
What does matter:
- The InfoConnect Agent app must be available in the tenant
- Shared-scope publishing ensures this
- Once available, agents surface automatically under Copilot
There is currently no official documentation that clearly explains this flow — which is why the error messages are so misleading.
Until MCP execution and multi-context support reach parity, Foundry agents in Teams should be treated as Copilot-style, prompt-only agents, not full bot replacements.
Hope this clarifies things — you’re definitely not doing anything wrong here.
Thanks for the detailed follow-up, Alexey — these behaviors are confusing, but they are consistent with how Foundry agents currently integrate with Teams.
I’ll answer your questions one by one.
1) Agent responds in Teams, but MCP tool calls fail
This is a known limitation of Azure AI Foundry agents in Teams today.
Key points:
- Foundry Playground runs agents inside Azure, where MCP servers are reachable.
- Microsoft Teams / M365 Copilot runs the agent through the InfoConnect Agent runtime, which has strict network and execution constraints.
- MCP servers must be:
- Publicly reachable over HTTPS
- Respond within tight latency limits
- Not require interactive auth, VPN, or private network access
In practice:
- Many MCP servers (including AS/400-backed services) work fine in Playground
- The same MCP servers fail silently or error in Teams
This is why:
- Simple prompts work
- Tool calls consistently fail
At the moment, MCP support in Teams is limited and not parity with Playground. This is a platform gap, not a configuration issue on your side.
2) Only one Foundry agent identity appears, with “no permissions”
This is expected behavior.
Foundry creates one shared Teams app (InfoConnect Agent) per tenant, not one per agent.
What you’re seeing:
- Multiple Foundry agents → same underlying Teams app
- Teams Admin Center shows:
- “The app doesn’t have any permissions”
This message is misleading:
- It does not refer to Entra ID, RBAC, or Graph permissions
- Foundry agents do not expose per-agent permission manifests in Teams
- Permissions are evaluated at runtime by Foundry, not Teams
So:
- You won’t see multiple app entries
- You won’t see meaningful permission details in Teams Admin Center
- This is by design (for now)
3) Agent does not appear in “Add agents and bots” for channels
This is also expected.
Foundry agents currently:
- Do NOT behave like traditional Teams bots
- Cannot be added via:
- Channel → Add agents and bots
Instead, they can only be used via:
- Teams → Copilot → My agents
- 1:1 Copilot-style interaction
Channel, meeting, and group-chat scenarios are not supported yet for Foundry agents.
That’s why:
- You can see them under Copilot / Manage apps
- But not in channel bot pickers
Important clarification about “installing” the agent
There is no separate per-agent installation step today.
What does matter:
- The InfoConnect Agent app must be available in the tenant
- Shared-scope publishing ensures this
- Once available, agents surface automatically under Copilot
There is currently no official documentation that clearly explains this flow — which is why the error messages are so misleading.
Until MCP execution and multi-context support reach parity, Foundry agents in Teams should be treated as Copilot-style, prompt-only agents, not full bot replacements.
Hope this clarifies things — you’re definitely not doing anything wrong here.
Thank you for your detailed response! It cleared out many questions