Problem: MCP connection only shows Cancelled via... (the real 401 auth error is hidden) —— Trove problem library

What you will run into

Your agent connects to an MCP server, the connection fails, and all you get is Cancelled via... — no 401, no permission hint; it looks like a cancellation. So you debug "cancellation" (retries, timeouts) and go nowhere: the real error is an HTTP 401 auth failure, wrapped into cancellation semantics by the error-handling layer.

Why this happens

Conclusion first: an MCP error-handling defect — HTTP auth 401 is wrapped as Cancelled via..., losing the real error name (issues #7699/#7704/#7656, open 2026-08; maintainers are fixing it to name the real error).

Chain: MCP client issues an HTTP request -> server returns 401 -> client error-wrapping layer -> shown as "Cancelled". The break is step three: missing error-semantics mapping — you see the wrapped symptom, not the root cause.

Conclusion: do not debug Cancelled as cancellation; verify credentials and permissions first (the real cause is usually a 401 / missing scope), or curl -i the MCP HTTP endpoint directly to read the raw status code — bypass the wrapper and get the original error.

Not reproduced: the full chain requires an LLM provider / Azure Foundry, so it was not reproduced here (stated honestly); the judgment is based on the upstream issues (three numbers, same phenomenon) plus the error-handling mechanism.

Step by step

1. Verify against the endpoint directly — Required

curl -i and read the status: 401/403 = credentials problem (the real root cause); 200 with Cancelled still = continue to the next step.

2. Check credentials and permissions — Required

Is the API key/header correct, and does the scope cover the capabilities of that MCP server?

3. Upgrade to the fixed release — By scenario

Once the upstream fix (naming the real error) ships, upgrading agent-framework restores readable errors.

4. If still unclear — Diagnostic

Capture MCP client logs / packets to confirm the request reaches the endpoint; attach the raw request info when following the issue.

How to confirm it works

• Failures report a real 401/403/named error instead of Cancelled;
• once credentials are fixed, the MCP connection establishes normally.

Other environments

• Enterprise / Azure Foundry chains: more auth layers, so 401 masking misleads even more;
• Local stdio MCP: different error shape (no HTTP status), so this entry mainly covers HTTP transport;
• Source material: microsoft/agent-framework issues #7699/#7704/#7656 (open, 2026-08), anonymous retrieval summary.

Symptom

The MCP connection fails and the client only shows "Cancelled via...", with the real auth error (401) invisible.

Cause

An MCP error-handling defect: HTTP auth 401 is wrapped as "Cancelled via..." (issues #7699/#7704/#7656, open 2026-08); maintainers are fixing it to name the real error.

Solution

1. Check credentials and scope first (the real cause is usually a 401 / insufficient permission) — do not debug by the Cancelled semantics.
2. Upgrade agent-framework to a release containing the error fix; as a workaround, curl the MCP HTTP endpoint directly (curl -i to see 401/403).