extendToM365 rejects rc.1 metadata-only server/discover supportedVersions

[krubenok]

Describe the bug
teamsApp/extendToM365 rejects an otherwise valid Remote MCP app after upgrading the C# MCP SDK from ModelContextProtocol 2.0.0-preview.2 to 2.0.0-rc.1.

The Package Service returns HTTP 400 with a nested validator HTTP 500 even though:

• server/discover returns HTTP 200.
• tools/list returns HTTP 200.
• All 46 advertised tools have object inputSchema values.
• Local app package validation and teamsApp/update succeed.

The failure is caused by the validator requiring an initialize-handshake protocol version in server/discover.supportedVersions. In 2.0.0-rc.1, discovery intentionally advertises only versions available through per-request metadata, so the response contains only 2026-07-28.

To Reproduce
Steps to reproduce the behavior:

1. Host a Remote MCP server over public HTTPS using ModelContextProtocol 2.0.0-rc.1.
2. Configure a RemoteMCPServer runtime with dynamic discovery.
3. Confirm server/discover.supportedVersions is ["2026-07-28"].
4. Run pnpm exec atk provision --env local.
5. Observe teamsApp/create, teamsApp/zipAppPackage, teamsApp/validateAppPackage, and teamsApp/update succeed.
6. Observe teamsApp/extendToM365 fail with:

BadRequest: Manifest package validations failed. Errors:
Internal Error - Failed to make a successful HTTP request.
Exception message: Response status code does not indicate success:
500 (Internal Server Error).

The behavior was isolated as follows:

• The preview.2 endpoint advertised ["2024-11-05", "2025-03-26", "2025-06-18", "2025-11-25", "2026-07-28"]; provisioning succeeded.
• The rc.1 endpoint advertised only ["2026-07-28"]; provisioning failed consistently.
• The tool catalogs were otherwise equivalent apart from generated widget resource hashes.
• Adding only "2025-11-25" alongside "2026-07-28" made extendToM365 succeed.
• This was reproduced both with a response proxy and with an outgoing server response filter.

Expected behavior
Package Service should accept the rc.1 metadata-only discovery semantics and successfully extend the app when server/discover.supportedVersions contains only "2026-07-28".

Screenshots
N/A

VS Code Extension Information (please complete the following information):

• OS: macOS
• Version: N/A; reproduced with the CLI

CLI Information (please complete the following information):

• OS: macOS
• Version: 1.1.12

Additional context
Related issue #15810 had the same opaque extendToM365 failure, but its root cause was a missing inputSchema. That is not the cause here: every advertised tool has an object inputSchema.

Example Package Service request IDs:

• 9f359d20-5c97-fba0-8abf-c2702b2e7b14
• b0ec1bfa-2e13-c854-dfd7-da329e5aa0ad
• 743bd491-5ce9-0d4e-82e5-d1dabaca315a

The current workaround is to inject "2025-11-25" into the server/discover.supportedVersions response. We would like to remove that compatibility workaround once Package Service accepts the rc.1 behavior.

[m365-agent-toolkit-assistant]

👋 Hi @krubenok,

Thank you for reporting this issue! We want to let you know that:

⏱️ Our team will personally review your issue
🎯 You can expect a response within 2 business days

✨ This is an AI-generated initial response
🤖 AI-Generated Preliminary Analysis:

Classification: Upstream — the evidence points to Package Service validation lagging behind current MCP dynamic-discovery behavior, not an ATK CLI defect.

• Learn docs say MCP plugins use dynamic tool discovery by default and fetch tools from the server at runtime; pinned republish is optional.
• Your repro isolates the break to server/discover.supportedVersions: ["2026-07-28"] fails, but adding "2025-11-25" makes extendToM365 pass.
• teamsApp/create, zipAppPackage, validateAppPackage, and update all succeed, which is consistent with a server-side validator mismatch during extendToM365.
• I found a similar opaque extendToM365 issue, but it was a different root cause (inputSchema): #15810.

Upgrade check: No changelog fix found in ATK stable releases, including CLI-era changes through 6.12.1 / CLI 1.1.12.

What to do now:

1. Keep the temporary workaround: advertise "2025-11-25" alongside "2026-07-28".
2. Include the Package Service request IDs when escalating internally.
3. Retry after a Package Service/backend rollout; no ATK upgrade fix is currently verified.

Useful links:

• OfficeDev/microsoft-365-agents-toolkit#15810 — Unable to publish: teamsApp/extendToM365 fails
• https://learn.microsoft.com/microsoft-365/copilot/extensibility/plugin-dynamic-tool-discovery
• https://learn.microsoft.com/microsoft-365/copilot/extensibility/overview-plugins

If you want, I can help draft a tighter escalation summary for the service team.

---

Note: This is an automated first response generated by AI. A human team member will review your issue and provide a more detailed response soon. We appreciate your patience!