Describe the bug
role_assignment_list returns an empty assignment array with
"status": 200, "message": "Success" for a management-group scope that
demonstrably has role assignments. The failure is silent — it is
indistinguishable from a genuine empty result.
Expected behavior
The assignments present at that scope — in our case Reader (acdd72a7-…)
and Cost Management Reader (72fafb9e-…) on the calling SP, plus four user
Owner assignments.
Actual behavior
The assignments present at that scope — in our case Reader (acdd72a7-…)
and Cost Management Reader (72fafb9e-…) on the calling SP, plus four user
Owner assignments.
Verification that the result is wrong
Two independent paths, same credential, same session:
arm / execute_query against authorizationresources returns six
management-group-scoped assignments, including the two on the calling SP.az role assignment list --all --assignee <appId> --include-inherited --include-groups under a separate identity returns the same two.
Reader includes Microsoft.Authorization/roleAssignments/read, so this is
not a permissions gap — and a permissions gap should surface as an error,
not as Success.
Why this matters beyond the empty array
The response echoes back no scope, so a caller cannot tell which scope was
actually queried. For an agent consuming this tool, a false empty is worse
than an error: it reads as positive evidence of absence. In our case it
produced a confident, well-formed, entirely wrong conclusion that a
production RBAC assignment was missing.
Reproduction Steps
- Assign Reader at
/providers/Microsoft.Management/managementGroups/<mg-id>
to a service principal.
- Configure the MCP server with that SP's credentials.
- Call
role_assignment_list with:
{"scope": "/providers/Microsoft.Management/managementGroups/<mg-id>"}
Environment
- Azure MCP Server 2.0 via
npx -y @azure/mcp@latest server start
- Client: Claude Code (VS Code extension), macOS
- Credential: service principal via
AZURE_TENANT_ID / AZURE_CLIENT_ID /
AZURE_CLIENT_SECRET, holding Reader + Cost Management Reader at the
management group being queried
Describe the bug
role_assignment_listreturns an empty assignment array with"status": 200, "message": "Success"for a management-group scope thatdemonstrably has role assignments. The failure is silent — it is
indistinguishable from a genuine empty result.
Expected behavior
The assignments present at that scope — in our case Reader (
acdd72a7-…)and Cost Management Reader (
72fafb9e-…) on the calling SP, plus four userOwner assignments.
Actual behavior
The assignments present at that scope — in our case Reader (
acdd72a7-…)and Cost Management Reader (
72fafb9e-…) on the calling SP, plus four userOwner assignments.
Verification that the result is wrong
Two independent paths, same credential, same session:
arm/execute_queryagainstauthorizationresourcesreturns sixmanagement-group-scoped assignments, including the two on the calling SP.
az role assignment list --all --assignee <appId> --include-inherited --include-groupsunder a separate identity returns the same two.Reader includes
Microsoft.Authorization/roleAssignments/read, so this isnot a permissions gap — and a permissions gap should surface as an error,
not as
Success.Why this matters beyond the empty array
The response echoes back no scope, so a caller cannot tell which scope was
actually queried. For an agent consuming this tool, a false empty is worse
than an error: it reads as positive evidence of absence. In our case it
produced a confident, well-formed, entirely wrong conclusion that a
production RBAC assignment was missing.
Reproduction Steps
/providers/Microsoft.Management/managementGroups/<mg-id>to a service principal.
role_assignment_listwith:{"scope": "/providers/Microsoft.Management/managementGroups/<mg-id>"}Environment
npx -y @azure/mcp@latest server startAZURE_TENANT_ID/AZURE_CLIENT_ID/AZURE_CLIENT_SECRET, holding Reader + Cost Management Reader at themanagement group being queried