Hi
@Vektori1
The resource=None entry is the key detail here.
In the MCP authorization specification, resource is the OAuth Resource Indicator and the MCP client is expected to include it in both the authorization and token requests, using the canonical MCP server URI.
Since the same server works with Claude and GitHub Copilot, and Copilot Studio is already able to discover its capabilities, this strongly points to the Copilot Studio OAuth/Dynamic Discovery flow rather than the MCP server itself.
There is also a very similar Power Platform Community case where Microsoft confirmed that Copilot Studio should obtain the resource value from the protected-resource metadata and include it in the OAuth request. When it is omitted, the authorization server can reject the request or issue a token for the wrong audience.
I would verify one thing server-side first: /.well-known/oauth-protected-resource should return the exact company-specific BiBook MCP URL, including the required subdomain, as its resource value.
If that is already correct and Copilot Studio still sends resource=None, I would not weaken the server-side validation. Recreate the connection using the company-specific MCP URL and capture both the authorization and token requests. If resource is still absent, this should be raised as a Copilot Studio interoperability issue with Microsoft, ideally including the HAR trace, protected-resource metadata, authorization-server metadata, and the resource=None server log.
Also, simply switching to Manual OAuth is not guaranteed to fix this: the current Copilot Studio MCP manual OAuth configuration does not expose a dedicated RFC 8707 resource field, so the actual outgoing request should be verified.
