MCP server URL or name
https://www.microsoft.com/releasecommunications/mcp
How are you connecting to this server?
From a custom connector URL I entered manually
Where does the issue occur?
When pressing the Connect button
When did you last reproduce this?
2026-06-05 15:00 UTC+12
Browser and OS
Google Chrome Version 149.0.7827.54 (Official Build) (64-bit) on Windows 11 version 24H2 (OS Build 26100.8390)
Describe the issue
Summary
Org-managed custom connectors in Claude Desktop appear to assume OAuth 2.1 for all remote MCP servers and attempt Dynamic Client Registration on connect. There is no way in the admin UI to declare that a server is unauthenticated, and the connect flow fails against MCP servers that intentionally expose no OAuth metadata.
This affects integrations with anonymous public MCP servers, including Microsoft's own Release Communications MCP Server, which Microsoft documents as requiring no authentication.
Environment
Claude Desktop version: 1.6608.2.0 (Windows MSIX package)
OS: Windows 11
Plan: Team/Enterprise (org-managed connectors enabled)
Connector type: Custom (organization-managed)
Transport advertised by server: Streamable HTTP
Steps to reproduce
As an org admin, go to claude.ai/admin-settings/connectors → Add custom connector.
Configure:
Name: Microsoft Release Communications
URL: https://www.microsoft.com/releasecommunications/mcp
Leave OAuth Client ID and OAuth Client Secret blank under Advanced settings.
Save the connector and enable it for the organization.
As an end user in Claude Desktop, go to Customize → Connectors, select the new connector, and click Connect.
Error details
Actual behavior
Clicking Connect opens a browser tab at claude.ai/desktop/connected/customize/connectors?&server=<server-id>.
The tab shows "Couldn't connect — Taking you back to the desktop app. You can close this tab."
Claude Desktop displays the following toast:
"Couldn't register with Microsoft Release Communications's sign-in service. You can try again, or add an OAuth Client ID in the connector settings. If this persists, share this reference with support: "ofid_ac7b613a996f9627"
The phrasing "Couldn't register with [...] sign-in service" indicates the flow is attempting OAuth Dynamic Client Registration against the MCP server, which has no DCR endpoint (or any OAuth metadata) by design. Each retry generates a different ofid_ reference.
Expected behavior
Expected behavior
Claude Desktop should either:
(a) attempt to connect to the URL anonymously (no auth headers) and succeed, since the server requires no auth; or
(b) provide an explicit Authentication type selector in the admin UI with options including None / Anonymous, allowing the admin to declare the auth model up front.
Microsoft's official documentation for the MRC MCP Server states "no authentication is required" and supplies the canonical client config:
json{ "servers": { "MRC-MCP-Server": { "type": "http", "url": "https://www.microsoft.com/releasecommunications/mcp" } } }
Reference: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/mrc-mcp
Additional context
Workaround (works, but doesn't scale)
A local claude_desktop_config.json entry using the mcp-remote stdio bridge connects to the same URL successfully and exposes the four MRC tools (get_recent_m365_roadmaps, get_m365_roadmap_by_id, get_recent_azure_updates, get_azure_update_by_id):
json{
"mcpServers": {
"MRC-MCP-Server": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://www.microsoft.com/releasecommunications/mcp"]
}
}
}
This confirms the issue is not with the MCP server or the URL — it is specifically in the custom-connector code path's assumption that remote MCP servers speak OAuth. The stdio bridge bypasses that path entirely.
Drawbacks of the workaround: requires Node.js installed per workstation, not centrally manageable via the org-managed connector framework, and doesn't allow tool-level approval governance available in custom connectors.
Suggested fix
Either or both:
Add an Authentication type selector to the custom-connector admin UI, with at minimum OAuth 2.1 and None options. When set to None, skip the OAuth discovery/DCR steps and connect anonymously over the declared transport.
Make OAuth discovery best-effort. If a GET /.well-known/oauth-authorization-server (or equivalent OAuth metadata endpoint) returns 404, fall back to anonymous HTTP rather than failing the connect with a "couldn't register" error.
Option 1 is the cleaner long-term answer because it makes admin intent explicit and avoids ambiguity when an MCP server exposes partial OAuth metadata.
Why this matters
The Microsoft Release Communications MCP Server is one of the first widely-promoted production MCP integrations from a major vendor. It is explicitly documented as compatible with "Claude Code and other MCP-compatible clients" — the omission of Claude Desktop in that list appears to be precisely because of this limitation. Other public/data-feed style MCP servers are likely to follow the same anonymous-HTTP pattern.
Centrally-managed unauthenticated remote MCP support would also remove the per-workstation Node.js dependency that the current workaround requires, which is a meaningful blocker for organizations with strict managed-device policies.
MCP server URL or name
https://www.microsoft.com/releasecommunications/mcp
How are you connecting to this server?
From a custom connector URL I entered manually
Where does the issue occur?
When pressing the Connect button
When did you last reproduce this?
2026-06-05 15:00 UTC+12
Browser and OS
Google Chrome Version 149.0.7827.54 (Official Build) (64-bit) on Windows 11 version 24H2 (OS Build 26100.8390)
Describe the issue
Summary
Org-managed custom connectors in Claude Desktop appear to assume OAuth 2.1 for all remote MCP servers and attempt Dynamic Client Registration on connect. There is no way in the admin UI to declare that a server is unauthenticated, and the connect flow fails against MCP servers that intentionally expose no OAuth metadata.
This affects integrations with anonymous public MCP servers, including Microsoft's own Release Communications MCP Server, which Microsoft documents as requiring no authentication.
Environment
Claude Desktop version: 1.6608.2.0 (Windows MSIX package)
OS: Windows 11
Plan: Team/Enterprise (org-managed connectors enabled)
Connector type: Custom (organization-managed)
Transport advertised by server: Streamable HTTP
Steps to reproduce
As an org admin, go to claude.ai/admin-settings/connectors → Add custom connector.
Configure:
Name: Microsoft Release Communications
URL: https://www.microsoft.com/releasecommunications/mcp
Leave OAuth Client ID and OAuth Client Secret blank under Advanced settings.
Save the connector and enable it for the organization.
As an end user in Claude Desktop, go to Customize → Connectors, select the new connector, and click Connect.
Error details
Expected behavior
Expected behavior
Claude Desktop should either:
(a) attempt to connect to the URL anonymously (no auth headers) and succeed, since the server requires no auth; or
(b) provide an explicit Authentication type selector in the admin UI with options including None / Anonymous, allowing the admin to declare the auth model up front.
Microsoft's official documentation for the MRC MCP Server states "no authentication is required" and supplies the canonical client config:
json{ "servers": { "MRC-MCP-Server": { "type": "http", "url": "https://www.microsoft.com/releasecommunications/mcp" } } }
Reference: https://learn.microsoft.com/en-us/microsoft-365/admin/manage/mrc-mcp
Additional context
Workaround (works, but doesn't scale)
A local claude_desktop_config.json entry using the mcp-remote stdio bridge connects to the same URL successfully and exposes the four MRC tools (get_recent_m365_roadmaps, get_m365_roadmap_by_id, get_recent_azure_updates, get_azure_update_by_id):
json{
"mcpServers": {
"MRC-MCP-Server": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://www.microsoft.com/releasecommunications/mcp"]
}
}
}
This confirms the issue is not with the MCP server or the URL — it is specifically in the custom-connector code path's assumption that remote MCP servers speak OAuth. The stdio bridge bypasses that path entirely.
Drawbacks of the workaround: requires Node.js installed per workstation, not centrally manageable via the org-managed connector framework, and doesn't allow tool-level approval governance available in custom connectors.
Suggested fix
Either or both:
Add an Authentication type selector to the custom-connector admin UI, with at minimum OAuth 2.1 and None options. When set to None, skip the OAuth discovery/DCR steps and connect anonymously over the declared transport.
Make OAuth discovery best-effort. If a GET /.well-known/oauth-authorization-server (or equivalent OAuth metadata endpoint) returns 404, fall back to anonymous HTTP rather than failing the connect with a "couldn't register" error.
Option 1 is the cleaner long-term answer because it makes admin intent explicit and avoids ambiguity when an MCP server exposes partial OAuth metadata.
Why this matters
The Microsoft Release Communications MCP Server is one of the first widely-promoted production MCP integrations from a major vendor. It is explicitly documented as compatible with "Claude Code and other MCP-compatible clients" — the omission of Claude Desktop in that list appears to be precisely because of this limitation. Other public/data-feed style MCP servers are likely to follow the same anonymous-HTTP pattern.
Centrally-managed unauthenticated remote MCP support would also remove the per-workstation Node.js dependency that the current workaround requires, which is a meaningful blocker for organizations with strict managed-device policies.