Capture MSAL exception details

[alzimmermsft]

What does this PR do?

Capture details from MsalServiceException and MsalServiceException in telemetry when they're thrown to help improve details for where the MCP server can improve.

GitHub issue number?

[Link to the GitHub issue this PR addresses]

Pre-merge Checklist

• Required for All PRs
  • Read contribution guidelines
  • PR title clearly describes the change
  • Commit history is clean with descriptive messages (cleanup guide)
  • Added comprehensive tests for new/modified functionality
  • Created a changelog entry if the change falls among the following: new feature, bug fix, UI/UX update, breaking change, or updated dependencies. Follow the changelog entry guide
• For MCP tool changes:
  • One tool per PR: This PR adds or modifies only one MCP tool for faster review cycles
  • Updated servers/Azure.Mcp.Server/README.md and/or servers/Fabric.Mcp.Server/README.md documentation
  • Validate README.md changes running the script ./eng/scripts/Process-PackageReadMe.ps1. See Package README
  • For new or modified tool descriptions, ran ToolDescriptionEvaluator and obtained a score of 0.4 or more and a top 3 ranking for all related test prompts
  • For tools with new names, including new tools or renamed tools, update consolidated-tools.json
  • For renamed tools, follow the Tool Rename Checklist and tag the PR with the breaking-change label
  • For new tools associated with Azure services or publicly available tools/APIs/products, add URL to documentation in the PR description
• Extra steps for Azure MCP Server tool changes:
  • Updated command list in servers/Azure.Mcp.Server/docs/azmcp-commands.md
  • Ran ./eng/scripts/Update-AzCommandsMetadata.ps1 to update tool metadata in azmcp-commands.md (required for CI)
  • Updated test prompts in servers/Azure.Mcp.Server/docs/e2eTestPrompts.md
  • 👉 For Community (non-Microsoft team member) PRs:
    • Security review: Reviewed code for security vulnerabilities, malicious code, or suspicious activities before running tests (crypto mining, spam, data exfiltration, etc.)
    • Manual tests run: added comment /azp run mcp - pullrequest - live to run Live Test Pipeline

[Copilot]

Pull request overview

This PR enhances error handling/telemetry in Microsoft.Mcp.Core by capturing additional (intended PII-safe) details for MSAL-related exceptions and mapping MsalServiceException to an HTTP status code, aiming to improve diagnostics when authentication flows fail.

Changes:

• Add MsalServiceException HTTP status code mapping in GlobalCommand.GetStatusCode.
• Update BaseCommand.HandleException to emit structured exception telemetry (status + error code + IDs) for RequestFailedException, MsalServiceException, and MsalClientException.
• Extend BaseCommand.GetStatusCode to map RequestFailedException and MsalServiceException.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
core/Microsoft.Mcp.Core/src/Commands/GlobalCommand.cs	Maps MsalServiceException to an HTTP status code.
core/Microsoft.Mcp.Core/src/Commands/BaseCommand.cs	Emits structured exception details into telemetry tags and expands status-code mapping.

[jongio]

Clean refactoring - the shared exceptionDetails object eliminates duplication between branches and makes it straightforward to add new exception types.

The bot's point about CorrelationId vs RequestId naming is the key item to address before merge. Mixing MSAL correlation IDs with Azure service request IDs under the same "RequestId" key will make telemetry queries confusing - they're semantically different identifiers from different systems. Consider "CorrelationId" for MSAL and keep "RequestId" for ClientRequestId.

One nice side effect: commands extending BaseCommand directly (not via GlobalCommand) now get correct HTTP status codes for RequestFailedException instead of a blanket 500.

Nit: the comment on line 95 ("this is the only PII safe property") should be reworded since ErrorCode and request/correlation IDs are also added below. Something like "Start with the status code, then add PII-safe diagnostic properties per exception type" would be clearer.

[jongio]

Addresses my previous feedback. The CorrelationId rename is correct and eliminates the semantic confusion with Azure SDK's ClientRequestId.

Nit: Line 114 comment says "correlation code" - should be "correlation ID".