fix(fx-core): make MCP OAuth metadata discovery robust and failures visible

[Alive-Fish]

Fixes #16451

Problem

Scaffolding a declarative agent against an MCP server could silently produce an m365agents.yml that cannot provision, with no signal to the developer. Two customer reports trace back to the same shape of failure.

Report A (#16451) — dcr/register was written with wellKnownAuthorizationServer: . The warning existed but never reached the UI; provision later failed with the opaque DcrWellKnownInvalidError.

Report B — oauth/register was written with the authorizationUrl and tokenUrl keys simply absent:

- uses: oauth/register
  with:
    name: mcpserver
    appId: ${{TEAMS_APP_ID}}
    flow: authorizationCode
    identityProvider: Custom
    baseUrl: https://.../mcp

Root causes

Six independent defects, each verified by live probing against the actual servers involved.

1. Discovery implemented only one of the two MCP auth generations

Two generations are in the wild:

Generation	Chain	401 challenge
2025-06-18 (RFC 9728)	resource_metadata="…" → protected-resource doc → authorization_servers[0] → well-known on the issuer	carries resource_metadata
2025-03-26	the MCP server is its own authorization server; RFC 8414 metadata sits at the origin root; no protected-resource doc exists	carries only realm / error

ATK implemented only the first, so against a 2025-03-26 server the chain dead-ended at step one and endpoints came back empty. This is the defect behind the reported repro.

2. Well-known discovery only ever tried one URL form

RFC 8414 defines the insertion form, but many providers only answer the append form, and some only answer OpenID Connect discovery. For the issuer in report B:

Candidate	Result
login.microsoftonline.com/.well-known/oauth-authorization-server/common/v2.0 — the only one ATK tried	404
login.microsoftonline.com/common/v2.0/.well-known/oauth-authorization-server	404
login.microsoftonline.com/.well-known/openid-configuration/common/v2.0	404
login.microsoftonline.com/common/v2.0/.well-known/openid-configuration	200

The 404 threw, the catch left endpoints = {}, and the injector wrote undefined for both URLs — producing exactly the YAML above.

3. MCP warnings were silently dropped

Declarative-agent projects carry the copilotGpt capability, so ShowScaffoldingWarningSummary routes to generateScaffoldingSummary — an allowlist that only formats six spec-parser WarningTypes plus manifest-length warnings. All MCP warning types fell through it, including the placeholder warning that report A depended on.

4. oauth/register had no placeholder path

dcr/register already degraded gracefully to a fill-in placeholder. The static oauth path did not — it emitted undefined, and the YAML serializer dropped the keys entirely, leaving nothing for the developer to notice or edit.

5. Discovery started only from a 401 challenge

A server hands out the location of its protected-resource document inside WWW-Authenticate. A server that authorizes the individual tool calls rather than initialize never sends one — Google's Gmail, Calendar and Drive servers answer an unauthenticated initialize with 200 and a complete JSON-RPC result:

{"id":1,"jsonrpc":"2.0","result":{"capabilities":{…},"protocolVersion":"2025-03-26",
 "serverInfo":{"name":"StatelessServer","version":"ESF"}}}

With no resource_metadata to follow, discovery fell straight through to defect 1's fallback and treated the server as its own authorization server. Every one of those candidates 404s, so the YAML got placeholders:

Candidate	Result
all six oauth-authorization-server / openid-configuration forms on drivemcp.googleapis.com	404
drivemcp.googleapis.com/.well-known/oauth-protected-resource/mcp/v1 — never tried	200, authorization_servers: ["https://accounts.google.com/"]

The document was there the whole time. RFC 9728 §3.1 derives its location from the resource URL by inserting the well-known segment between host and path, so a client never needs to be told.

6. A 4xx was read as proof of a wrong URL

The URL check blocks on 404, justified by "no valid endpoint in the sample ever returned one". Checking that claim against the transport spec rather than against the sample turns up a valid server that must:

Attempt to POST an InitializeRequest to the server URL… If it fails with an HTTP 4xx status code (e.g., 405 Method Not Allowed or 404 Not Found): Issue a GET request to the server URL, expecting that this will open an SSE stream and return an endpoint event as the first event.

— Streamable HTTP · Backwards Compatibility

A 2024-11-05 HTTP+SSE server has no streamable-HTTP endpoint to POST to, so a 4xx is its normal answer to the probe — and 404 is the shape that blocks at input time. The measurements could not have caught this: every /sse path probed is either a streamable-HTTP endpoint or authorization-gated ahead of transport dispatch, so the case is missing from the sample rather than missing from the world.

Changes

Both auth generations are now probed. When no protected-resource document is advertised, resolveMCPOAuthMetadata falls back to well-known candidates derived from the MCP server URL itself, including its origin root. The two candidate ladders are deliberately different: candidates derived from an issuer never include origin-root forms, because for a tenant-scoped issuer the root form can return a valid-but-wrong-tenant document, which is worse than failing.

Multi-candidate discovery — the four forms (insertion/append × oauth-authorization-server/openid-configuration) are probed in order, accepting the first response carrying both authorization_endpoint and token_endpoint, so a 200 from a partial document does not shadow a later complete one. An explicitly configured wellKnownUrl is still used verbatim and never substituted. On total failure the error lists every URL attempted, which turns an unactionable message into a diagnosable one.

The protected-resource document is derived, not waited for. Between the advertised resource_metadata chain and the "server is its own authorization server" fallback, discovery now probes the RFC 9728 locations derived from the MCP server URL — §3.1 insertion first, origin root second. It runs only when nothing was advertised, so servers that do challenge are unaffected. Insertion goes first because it is the form that generalizes: of the five servers measured, all five serve it and api.githubcopilot.com 404s the origin-root form.

Warning pass-through — generateScaffoldingSummary now admits MCP warnings. The predicate is a prefix check rather than a hardcoded list: MCP warning types are camelCase with an mcp prefix (mcpAuthRequired, mcpNoToolsFetched, mcpAuthOAuthUrlPlaceholder, …) while spec-parser types are kebab-case (operationid-missing, generate-card-failed, …). Verified against the actual WarningType enum — no collision. This covers every MCP type at once, cannot drift as new ones are added, and does not leak the spec-parser warnings that the API-plugin and message-extension flows deliberately suppress.

OAuth URL placeholders — the injector now writes the angle-bracketed tokens PLEASE_FILL_IN_AUTHORIZATION_URL / PLEASE_FILL_IN_TOKEN_URL and reports it, mirroring the existing dcr/register behaviour. Substitution applies only to static oauth; entra-sso resolves its endpoints from Entra at provision time and must not be given placeholders. Implemented in both the v3 injector and the v4 YAML mutator, and wired into all six call sites.

A notification the developer cannot miss — the placeholder case now raises a VS Code notification with Open m365agents.yml and Create New App actions, rather than only appending to the output channel.

The misleading next-step invitation is suppressed — a project holding fill-in placeholders cannot provision, debug, or preview, so offering those as the next step sends the developer into a guaranteed failure. showLocalDebugMessage now takes a suppression flag; the stale-invitation global state is still consumed so it cannot resurface on the next window open.

A wrong MCP server URL is reported. Falling back to the MCP server's own origin made one case worse: a mistyped URL resolves that host's authorization server, which is correct for the host but useless for the agent. The paths that fetch tools detect this independently (a wrong URL yields zero tools), but the dynamic-tool-discovery path performs no tool fetch by design and had no backstop. The probe now uses an initialize POST and classifies the URL into three states instead of reporting only whether authorization is required:

State	Produced by	Effect
confirmed	401, or 2xx carrying a JSON-RPC envelope	none
notEndpoint	403, 404, 405, or 2xx without one	404 blocks at input; the rest warn after scaffolding
undetermined	5xx, other statuses, timeouts, transport failures	none

A 2xx status alone is not proof — substrate-sdf.office.com/ answers the same POST with 200 and HTML — so the JSON-RPC envelope in the body is what confirms the endpoint. The body text is searched rather than the frames parsed, which makes the check work for the text/event-stream framing streamable-HTTP servers reply with. This also makes "no authorization required" a real answer rather than the absence of one: learn.microsoft.com/api/mcp serves its three tools unauthenticated, and previously that outcome was indistinguishable from a DNS failure.

A 4xx no longer settles that verdict on its own. Before reporting notEndpoint, the probe performs the GET the spec prescribes and looks for the endpoint event a legacy HTTP+SSE server opens with. Only the rejection path pays the extra round-trip — a confirmed or undetermined URL never does. The stream is read only as far as that event and abandoned on an 8 KB cap and a 5 s timeout, so a talkative or hanging stream cannot stall the question walk. 400 is deliberately still not a negative signal, for a reason the same spec supplies: a server must answer 400 when it rejects the MCP-Protocol-Version, so a valid endpoint can produce one — as Google's servers do for any unroutable path.

Create and "add MCP server" now share one rule. The add-action question tree was a structural copy of the create subtree that never mirrored its validation, so a URL the create flow rejects outright was accepted without a word when added to an existing project. Both nodes now call the same validateMCPServerUrl, and the dynamic-tool-discovery branch of addPlugin raises the same notEndpoint warning as create. The non-DT branch is unchanged on purpose: it fetches tools and already warns via mcpNoToolsFetched, exactly as create does.

A URL with no scheme is rejected on shape, before the probe. taskmaster-mcp-server.azurewebsites.net was accepted while https://taskmaster-mcp-server.azurewebsites.net was blocked, which made the rule look arbitrary. axios cannot build a request from a scheme-less value, so the probe threw before any round-trip, reported no status, and the URL fell through as undetermined. The check is syntactic — an absolute http/https URL or nothing — so it does not touch which server answers may block. http stays allowed: a locally hosted MCP server is a normal thing to point at.

Adding an action surfaces the placeholder case too. addPlugin wrote oauth/register with placeholders and pushed a warning that only ever reached the output channel — then showed a success notification, so the developer was told the action was added and discovered the placeholders when provision failed. The create flow raises this case to a notification through a path add-action does not go through; add-action now raises it itself, with an action that opens the file holding the placeholders. VS Code only — the CLI already prints every warning through the log provider.

What the developer sees

The two checks are independent, and each has its own signal.

A URL that is not an MCP endpoint is rejected while it is being typed, in create and in "add MCP server" alike:

A URL can be a valid MCP server and still not publish the OAuth details we need — several public MCP servers behave this way. Scaffolding then succeeds with placeholders in m365agents.yml, and the developer is told before provision rather than after:

Evidence

Measured against nine reachable production MCP endpoints and fourteen truncated forms. Full table in the new fact page.

	POST	GET
8 valid endpoints (GitHub Copilot, Monday, HubSpot, Notion, Canva, Moody's, LSEG, + eval server)	401 — none returned 404	401
learn.microsoft.com/api/mcp (valid, no auth)	200, text/event-stream, JSON-RPC result	405 HTML
mcp.canva.com/, taskmaster-mcp-server.azurewebsites.net/ (truncated)	404	200 HTML / JSON
api.githubcopilot.com/, mcp.monday.com/, mcp.notion.com/, api.analytics.lseg.com/lfa/ (truncated)	404	404
learn.microsoft.com/api/ (truncated)	405	404
learn.microsoft.com/api, learn.microsoft.com/ (truncated)	403 Akamai	404 / 200 HTML
substrate-sdf.office.com/ (truncated)	200 HTML	200 HTML
api.moodys.com/genai-ready-data/m1/ (truncated)	401	401

Five findings shaped the implementation:

• GET is not a usable probe. Canva's origin root answers GET with 200 HTML while answering POST with 404, so a GET-based check clears a wrong URL. Conversely Learn's valid endpoint answers GET with 405. Hence the POST probe.
• 404 has 100% precision but only 6/12 recall. No valid endpoint produced a 404, so it never cries wolf — it is the blocking signal. Widening to the other measured negative shapes (403, 405, 2xx without an envelope) would raise recall to 10/12, but "no valid endpoint in this sample produced them" is not the same as "no valid endpoint can".
• Those wider shapes are weaker evidence, so they warn rather than block. A 404 says the path does not exist, which a working endpoint cannot say about itself. 405 says the opposite — the path routed, and only the method was refused — which is precisely what MCP's legacy HTTP+SSE transport does at its GET-only SSE endpoint; blocking on it would reject a URL class the spec still defines, and Learn's own valid endpoint answers GET with 405. Both measured 403s came from Akamai intercepting ahead of the application, and a WAF fronting a valid endpoint could reject the probe the same way. A 2xx with no envelope is also that legacy transport's normal POST ack, whose JSON-RPC result arrives on the separate SSE stream. Wrongly blocking a legitimate URL is worse than missing a wrong one.
• The negative statuses are enumerated, not generalised to "any 4xx". 429 and 408 are transient and would slander a URL that is in fact correct.
• 5xx means unreachable, not wrong, and URL shape carries no signal: HubSpot's endpoint is the origin root, and Monday's is /sse. No shape heuristic is admissible.

The one miss worth knowing about is Moody's: its gateway mounts authorization on the path prefix, so the truncated URL returns a well-formed 401 carrying a resource_metadata document, and discovery succeeds with plausible-but-wrong endpoints. No status-code rule can catch that.

The shipped rule was then re-run end-to-end against all twenty URLs, calling the validator itself over the real network rather than reasoning from the table: 8/8 valid endpoints accepted (zero false positives), 6 of the truncated forms blocked, 4 accepted with a warning (405 / 403 / 403 / 200-without-envelope), and the scheme-less form blocked by the shape check. Moody's truncated URL is the one silent miss, exactly as predicted.

That 8/8 was a weaker guarantee than it looked, and closing the gap is defect 6. Every valid endpoint in the sample is auth-gated and answers 401 before transport dispatch, so none of them ever exercised a method restriction — a follow-up probe of the /sse paths on Monday, Notion, GitHub and HubSpot returned 401 to both POST and GET. An unauthenticated legacy SSE server, the realistic http://localhost case, is not represented at all, and zero observed false positives out of eight bounds the true rate only at ~31% with 95% confidence. Rather than widen the sample, the spec-prescribed GET now rules that class out by construction.

Discovery was re-verified the same way — resolveMCPOAuthMetadata called over the real network with no advertised metadata URL, as the scaffold flow calls it:

Server URL	Resolved
gmailmcp.googleapis.com/mcp/v1	accounts.google.com/o/oauth2/v2/auth + oauth2.googleapis.com/token
calendarmcp.googleapis.com/mcp/v1	same
drivemcp.googleapis.com/mcp/v1	same
mcp.notion.com/mcp	mcp.notion.com/authorize + /token (unchanged)
api.githubcopilot.com/mcp	github.com/login/oauth/authorize + /access_token (now resolves without a challenge too)
learn.microsoft.com/api/mcp	fails, correctly — that server requires no authorization

Finally the whole rule was swept over every server named in this PR — 32 URLs, calling probeMCPServerAuth and resolveMCPOAuthMetadata over the real network:

	Result
13 documented endpoints	12 confirmed, 1 undetermined (substrate-sdf, ring still 503) — zero false positives
the 11 of those that publish authorization metadata — 8 that challenge with 401, plus Google's 3 that never challenge	11/11 OAuth endpoint pairs resolved
learn.microsoft.com/api/mcp	discovery fails, correctly — no authorization required
14 truncated forms	10 classified notEndpoint; 4 missed — Moody's path-prefix 401, substrate-sdf's 503, and two Google forms answering 400

Two further observations from that sweep are recorded on the fact page:

• Google serves its protected-resource document for any path prefix and echoes the requested path back in resource, so a wrong-but-plausible Google URL still resolves to real endpoints — the same class of miss as Moody's, and RFC 9728 §3.3's resource check cannot catch it.
• The reverse case is caught: api.githubcopilot.com/mcp/sse is not an endpoint but answers 401 from a gate ahead of routing, advertising a resource_metadata document that itself answers 401 — no candidate resolves, so the wrong URL surfaces one stage after the probe rather than by it.

Net effect is one invariant: ATK never silently produces an unprovisionable auth configuration. Either discovery succeeds, or the YAML contains a conspicuous placeholder and the developer is told about it.

Docs

• docs/02-architecture/external-dependencies/mcp-remote-servers.md + code map — external-dependency fact page recording the measured wire behavior, with a reproduction recipe so the table can be re-verified when servers change.
• ADR-0020 (Accepted) — where the URL-validity check belongs and whether it should block. Six options captured; the decision is the two-tier rule above, with the reasoning for rejecting both pure positive validation and a uniform block recorded. Its zero-false-positive premise is now qualified by the spec-mandated HTTP+SSE case and the construction that handles it.

Tests

Full suites green, eslint clean.

• fx-core — 291 files, 5282 passed, 0 failed
• vscode-extension — 93 files, 1090 passed, 0 failed

New coverage:

• Entra-style fallback where only the fourth candidate answers
• a candidate returning 200 without both endpoints is skipped, not accepted
• discovery failure lists all attempted candidates
• an explicit wellKnownUrl issues exactly one request
• candidate ordering, host-only dedupe, trailing-slash normalisation
• origin fallback when no resource_metadata is advertised, and when the advertised document is unreachable
• the protected-resource document is derived from the server URL when nothing advertised one — both the §3.1 insertion location and the origin root — and the origin-root well-known guess is then never issued
• derived-candidate ordering, host-only dedupe, trailing-slash normalisation
• an advertised authorization server is preferred over the origin
• oauth with no endpoints, and with only one of the two, both write placeholders and set the flag
• entra-sso is not given placeholders
• the summary surfaces an MCP warning while still hiding a suppressed spec-parser warning
• a 200 confirms the endpoint only when it carries a JSON-RPC envelope, including SSE-framed
• 403 / 404 / 405 mark the URL as not an endpoint; 401 confirms it; 429, 5xx and transport errors leave it undetermined
• a 4xx that turns out to be the deprecated HTTP+SSE transport is confirmed rather than rejected, and the notEndpoint verdict stands when the fallback GET is not an event stream, names no endpoint, errors out, or runs past the byte cap
• the URL question blocks a 404 and accepts every other outcome, including 403, 405 and a 200 without an envelope
• the DT path warns on a 404 server URL, warns on a 403, and stays quiet when the probe learned nothing
• the "add MCP server" question rejects the same 404 the create flow does, and accepts everything else
• both questions reject a value that is not an absolute http(s) URL, without contacting the server, and still accept http://localhost
• addPlugin on the DT path warns when the probe reports the URL is not an endpoint
• addPlugin notifies in VS Code when the yml is left with OAuth placeholders, and its action opens that file
• the next-step notification is suppressed only while the project cannot provision

Scope

Deliberately not in this PR:

• surfacing a confirmed endpoint to the user as positive feedback at input time — the probe now distinguishes the state, nothing renders it
• gating dynamic client registration when the URL is known-wrong, so provision does not register an OAuth client against a host the user never intended
• a manual well-known override for v4, which v3 has and v4 does not

[github-actions]

✅ VscUse Test Plan — All tests passed

Why these tests: All changed files are in packages/fx-core MCP OAuth scaffolding paths; the fix targets MCP OAuth metadata discovery for declarative agents, so DA_MCP_Oauth_Remote is primary, with DA_MCP_None_Remote and DA_MCP_Entra_SSO_Remote as related MCP auth sanity checks, and Feature_DA_Add_MCP_Server to cover the end-to-end DA+MCP scaffold flow.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 4 passed · ❌ 0 failed (of 4 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	✅ All tests passed (4/4 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

E2E Test Selection — AI Selected

Why these tests: Changes in packages/fx-core (MCP auth scaffolding, declarative agent helpers, question nodes) trigger teamsApp/, teamsAgent/, and all declarativeAgent/* tests (especially MCP variants); changes in packages/vscode-extension (autoOpenHelper, telemetry) additionally bring in all feature/* and teamsApp/* tests per rules 1 and 3.

Cases selected (27):

• ./teamsApp/basicBot.tests.ts
• ./teamsApp/basicMessageExtension.tests.ts
• ./teamsApp/basicTab.tests.ts
• ./teamsAgent/DebugCustomCopilotBasicBot.tests.ts
• ./teamsAgent/teamsCollaboratorAgent.tests.ts
• ./teamsAgent/DebugCustomCopilotRagAiSearchBot.tests.ts
• ./teamsAgent/DebugCustomCopilotRagBasicBot.tests.ts
• ./declarativeAgent/DeclarativeAgentWithEntra.tests.ts
• ./declarativeAgent/DeclarativeAgentInvalidManifestShape.tests.ts
• ./declarativeAgent/mcp/DeclarativeAgentMCPNoAuth.tests.ts
• ./declarativeAgent/mcp/DeclarativeAgentMCPAuthEdgeCases.tests.ts
• ./declarativeAgent/mcp/DeclarativeAgentMCPWithAuth.tests.ts
• ./declarativeAgent/DeclarativeAgentBasic.tests.ts
• ./declarativeAgent/typespec/typespec.withoutAction.tests.ts
• ./declarativeAgent/typespec/typespec.withAction.tests.ts
• ./declarativeAgent/addKnowledge/AddWebSearchByUrl.tests.ts
• ./declarativeAgent/addKnowledge/AddWebSearchByAll.tests.ts
• ./declarativeAgent/DeclarativeAgentWithApiKeyAuth.tests.ts
• ./declarativeAgent/DeclarativeAgentWithOAuth.tests.ts
• ./declarativeAgent/DeclarativeAgentWithNoneAuth.tests.ts
• ./feature/helpInfo.tests.ts
• ./feature/OpenV5ProjectByCli1.2.5.tests.ts
• ./feature/mosApi/sideloading.tests.ts
• ./feature/jsonFormatAndMultipleDeployment.tests.ts
• ./feature/Permission.tests.ts
• ./feature/accountCommand.tests.ts
• ./feature/multienv.tests.ts

---

View pipeline run

Need to run more tests?

Comment on this PR:

• /e2e-run ./path/to/test.tests.ts — add specific cases to AI selection
• /e2e-run-all — run all e2e cases

Then re-run the workflow.

[github-actions]

❌ VscUse Test Plan — Tests unknown

Why these tests: All changed files are in packages/fx-core relating to MCP OAuth metadata discovery and declarative agent scaffolding; selected the three DA_MCP_* remote plans to cover the OAuth/Entra/none auth paths, plus the two Feature plans that exercise adding an MCP server and configuring OAuth auth from the VS Code UI.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• DA_MCP_None_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests unknown

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent helper) and also touches vscode-extension autoOpenHelper/telemetry, so the most relevant plans cover DA MCP OAuth/Entra remote flows and the DA MCP server/OAuth auth Feature plans.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 4 passed · ❌ 1 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• DA_MCP_None_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (4/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery in declarativeAgent helper and mcpAuthScaffolder, directly exercising MCP OAuth/auth scaffolding flows and the DA Add MCP Server feature path.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 4 passed · ❌ 1 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (4/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests unknown

Why these tests: PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent/helper) — the most directly relevant plans cover DA MCP OAuth remote flow, DA OAuth action import, DA OAuth auth configuration feature, and DA MCP server addition as a sanity check.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Plans run:

• DA_MCP_Oauth_Remote
• DA_Add_Action_Import_Existing_API_Basic_OAuth
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations
• Feature_DA_Add_MCP_Server
• DA_MCP_None_Remote

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests unknown

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests unknown

Why these tests: PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (fx-core mcpAuthScaffolder, mcpAuthAction, declarativeAgent helper) and touches vscode-extension autoOpenHelper/telemetry, so MCP-specific DA plans and DA OAuth/auth configuration feature plans are most relevant.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• DA_MCP_None_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests unknown

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery bugs in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, helper files), directly exercised by DA MCP OAuth/None/Entra remote plans and the Feature DA MCP/OAuth auth configuration plans.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 4 passed · ❌ 1 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (4/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery bugs in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent/helper), directly exercising DA MCP OAuth flows and DA OAuth auth configuration features.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 2 passed · ❌ 3 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_Add_Action_Import_Existing_API_Basic_OAuth
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations
• Feature_DA_No_Action_Add_PKCE_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (2/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery for declarative agents — DA_MCP_Oauth_Remote directly covers the OAuth registration fix; DA_MCP_None_Remote and DA_MCP_Entra_SSO_Remote provide regression coverage for the other MCP auth paths; Feature_DA_Add_MCP_Server covers the VS Code scaffolding flow touched by mcpAuthScaffolder/autoOpenHelper changes.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure

🔗 Full pipeline results

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (mcpAuthScaffolder.ts, mcpAuthAction.ts, declarativeAgent/helper.ts), so MCP-specific DA plans and OAuth/auth configuration Feature plans are the most relevant.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 2 passed · ❌ 3 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (2/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery bugs in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent/helper) and VS Code autoOpenHelper; DA_MCP_Oauth_Remote directly covers the OAuth flow being fixed, DA_MCP_Entra_SSO_Remote and DA_MCP_None_Remote provide related MCP auth coverage, and Feature_DA_Add_MCP_Server covers the VS Code extension MCP server addition flow.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 3 passed · ❌ 1 failed (of 4 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• DA_MCP_None_Remote
• Feature_DA_Add_MCP_Server

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (3/4 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: The PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent/helper) — DA_MCP_Oauth_Remote is the primary target; DA_MCP_None_Remote and DA_MCP_Entra_SSO_Remote cover adjacent MCP auth flows; Feature_DA_Add_MCP_Server covers the MCP server addition UI path; DA_Add_Action_Import_Existing_API_Basic_OAuth covers the OAuth action import flow also touched by the diff.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 3 passed · ❌ 2 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server
• DA_Add_Action_Import_Existing_API_Basic_OAuth

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (3/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

✅ VscUse Test Plan — All tests passed

Why these tests: The PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (fx-core mcpAuthScaffolder, mcpAuthAction, declarativeAgent helper) and touches vscode-extension autoOpenHelper, making DA_MCP_Oauth_Remote the primary target, DA_MCP_Entra_SSO_Remote relevant as a related auth-discovery path, and Feature_DA_Add_MCP_Server relevant for the VS Code extension flow changes.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 3 passed · ❌ 0 failed (of 3 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	✅ All tests passed (3/3 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery in declarative agent scaffolding (mcpAuthScaffolder, mcpAuthAction, declarativeAgent helper) and touches vscode-extension autoOpenHelper; selected MCP-specific DA plans plus OAuth auth configuration feature plan to cover all affected code paths.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 3 passed · ❌ 2 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_None_Remote
• DA_MCP_Entra_SSO_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (3/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.

[github-actions]

❌ VscUse Test Plan — Tests failure

Why these tests: PR fixes MCP OAuth metadata discovery for declarative agents; selected DA_MCP_* remote plans to cover the OAuth/Entra/None auth flows and Feature plans for MCP server addition and OAuth auth configuration in the VS Code extension.

Branch diff: fix/mcp-oauth-metadata-discovery → dev

Results: ✅ 4 passed · ❌ 1 failed (of 5 plans)

Plans run:

• DA_MCP_Oauth_Remote
• DA_MCP_Entra_SSO_Remote
• DA_MCP_None_Remote
• Feature_DA_Add_MCP_Server
• Feature_DA_No_Action_Add_OAuth_Auth_Configurations

---

Step	Status
1️⃣ Build VSIX (CD)	✅ Done
2️⃣ Build Docker image	✅ Done
3️⃣ Run UI tests	❌ Tests failure (4/5 passed)

🎯 Actual UI test run
🔗 Full pipeline results
📊 Detailed test report

ℹ️ How were these tests selected?

GitHub Copilot (Claude Sonnet 4.6, high reasoning) analysed the PR title, description, and the diff between
fix/mcp-oauth-metadata-discovery and dev
to pick the most relevant test plans from packages/tests/vscuse/Index.md.