Microsoft 365 Copilot shows "token store error, connector unavailable" for custom MCP connector even though OAuth token issuance succeeds

Question

Microsoft 365 Copilot shows "token store error, connector unavailable" for custom MCP connector even though OAuth token issuance succeeds

Thanaphop Parinyarat 0

We have a custom MCP server fronted by our own OAuth 2.0 Authorization Server, registered with Microsoft 365 Copilot as a statically-configured OAuth client with RFC 8707 "resource" indicator support and PKCE (S256) enforced.

Symptom: When a user tries to use the connector in Microsoft 365 Copilot, they get a generic error: "token store error, connector unavailable."

What we've verified on our side:

Our authorization-server logs show the full OAuth flow completing successfully and repeatedly for this client: authorize (login succeeded) -> token issued -> multiple token-rotation (refresh) cycles, over many hours, for real end-user subjects. No errors, no failed grants.
No Access log that hit mcp endpoint after trying to call mcp through copilot and copilot say "token store error, connector unavailable"

What we can't see from our side: Copilot's own OAuth client, its token store, and which broker/backend actually terminates the flow.
Question: Since our Authorization Server confirms a valid access token was issued but our server never receives a corresponding request, what could cause Copilot to fail silently between "token issued" and "calling the resource"? Is there a way to see the real underlying error instead of the generic "token store error" bubble -- e.g. via Copilot Developer Mode, admin center diagnostics, or M365 message center logs?

Ashlesha Pawar (Tata Consultancy Services Limited) 395 Reputation points Microsoft External Staff

2026-09-11T06:28:56.9266667+00:00
The successful /authorize, /token, and refresh operations on your authorization server do not necessarily mean Microsoft 365 Copilot successfully stored/retrieved the token or proceeded to invoke the MCP endpoint.

The flow should be considered as:

authorize → token issued → Microsoft token store/runtime → MCP invocation

Since you see no MCP access request, the failure may be occurring between token issuance and the resource call.

Please verify:

Enable Copilot Developer Mode and capture the debug information card. Microsoft documents this as the primary way to expose the underlying authentication error behind generic messages such as token store error, connector unavailable.

Ensure the MCP reference_id exactly matches the OAuth configuration ID in Teams Developer Portal.

Ensure the OAuth configuration Base URL exactly matches the MCP server URL, including path/port and trailing-slash consistency.

Set Restrict usage by app to Any Teams app. Microsoft notes that binding an MCP OAuth configuration to an existing Teams app ID can provision successfully but fail at runtime in Microsoft 365 Copilot.

Confirm the affected tenant is allowed by the organization restriction.

Verify the redirect URI is exactly: https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect

Ensure the token endpoint responds directly with HTTP 200; Microsoft documents that a 307 Temporary Redirect is unsupported.

Validate OAuth metadata, PKCE, protected-resource metadata, and the RFC 8707 resource value for exact/consistent URI handling.

These checks can help determine whether the failure is occurring during token-store/runtime processing before Copilot reaches the MCP endpoint.
Thanaphop Parinyarat 0 Reputation points

2026-09-11T07:39:13.3233333+00:00
Thank you for the detailed checklist -- we went through every item:

Developer Mode debug information card: captured. The chat response explicitly states the failure happens "during connector/tool initialization" (loading tools from the MCP server), not during a specific tool call. However, the structured debug JSON itself contains no error field, no token-store reference, and no entry for our connector at all in enabledPlugins/matchedFunctionCandidates/functionExecutions -- the connector doesn't appear in the telemetry at all, even though the chat text clearly shows Copilot attempted and failed to load it.

MCP reference_id vs OAuth configuration ID in Teams Developer Portal: verified matching.

OAuth configuration Base URL vs MCP server URL (path/port/trailing slash): verified exact match.

"Restrict usage by app" set to "Any Teams app": confirmed set correctly, not scoped to a specific app ID.

Tenant allowed by organization restriction: confirmed.

Redirect URI exactly https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect: confirmed exact match in our client registration.

Token endpoint responds with direct HTTP 200, not 307: confirmed via direct curl test against our token endpoint.

OAuth metadata, PKCE, protected-resource metadata, RFC 8707 resource value consistency: verified live and byte-exact. The "resource" value in our protected-resource metadata matches exactly (same casing, no trailing slash) what appears in every authorize/token/refresh log line for this client, and the same resolution function is used across the authorize and token endpoints so there's no code path where these values could diverge. PKCE (S256) is enforced end-to-end and completes successfully per our server logs.

We also tested our MCP and OAuth server against ChatGPT, Claude, and Gemini all three connect and work correctly, so this does not appear to be a general implementation defect on our side.

Given all of the above checks out on our end, and the Developer Mode debug telemetry shows no error content for our connector at all (empty arrays, no matching entry), is there a next diagnostic step or internal log/trace on the Microsoft 365 Copilot / connector platform side that could show why token-store lookup or tool discovery fails for this connector before any outbound call is made?

Raw debug info for reference:

{"capabilitiesDeveloperInfo":{"enabledCapabilities":[],"capabilityExecutions":[]},"pluginDeveloperInfo":{"enabledPlugins":[{"id":"7383f391-d451-417c-bc0f-47c8909675c5","version":"0.0.25","source":"AugmentationLoop"},{"id":"fdb70dfb-067d-432c-8d79-4ad6db6cf50e","source":"AugmentationLoop"},{"id":"8aca84a6-ff0a-49ec-8150-c3eb055cdae4","version":"0.0.13","source":"AugmentationLoop"},{"id":"0ca48d0e-e828-4f28-918a-5b3c3bd053df","version":"0.2.3","source":"AugmentationLoop"},{"id":"3895ea2f-4743-4085-94d0-5fd6c5900b1a","version":"0.1.1","source":"AugmentationLoop"},{"id":"f5a38b3b-d2b7-4780-a80b-d43454e6f00d","version":"0.1.1","source":"AugmentationLoop"},{"id":"b2d2a088-c140-4be3-a780-726bdda3f4f0","version":"0.1.1","source":"AugmentationLoop"},{"id":"52ab04a6-2d46-467b-9003-1fecdbfc7811","version":"0.1.2","source":"AugmentationLoop"},{"id":"0e013faa-f615-4a4d-af61-3bd253acd527","version":"0.1.1","source":"AugmentationLoop"},{"id":"bc88a16a-1187-4261-aa5e-33b0c367335d","version":"0.2.3","source":"AugmentationLoop"},{"id":"738546a0-49c1-4298-94fd-2228c599915a","version":"0.2.3","source":"AugmentationLoop"},{"id":"outlook_plugin","version":"1.1","source":"BuiltIn"},{"id":"1125dfa3-8ea2-4a4e-bde4-0150764e8342","source":"AugmentationLoop"},{"id":"10a43a5f-35ab-408e-9907-86e0965ce7a3","source":"AugmentationLoop"},{"id":"ce0d4772-20a1-4a16-b4a9-1ed0c909aeb0","version":"0.0.10","source":"AugmentationLoop"},{"id":"a1c3e5f7-9b2d-4f6a-8c0e-2d4f6a8b0c1e","version":"0.0.2","source":"AugmentationLoop"},{"id":"0a884c9c-0796-4246-8eff-fdc5bf68a6ba","version":"0.0.2","source":"AugmentationLoop"},{"id":"94e1e80c-b2cb-484b-81cc-b10f7599a91e","version":"0.0.2","source":"AugmentationLoop"},{"id":"68cbcba3-d63e-43a2-8db6-52520da54ce1","source":"AugmentationLoop"},{"id":"e7374a81-1e76-4bea-92c5-c0aeddf0d651","source":"AugmentationLoop"},{"id":"66b8dcb0-158c-45c4-ae80-db8621bfa63e","version":"0.1.2","source":"AugmentationLoop"},{"id":"10f45790-fba2-4da7-bad7-cf02d39d0ffe","source":"AugmentationLoop"},{"id":"calendar_cancel_meeting","version":"1.0","source":"BuiltIn"},{"id":"calendar_manage_categories","version":"1.0","source":"BuiltIn"},{"id":"calendar_update_meeting","version":"2.0","source":"BuiltIn"},{"id":"calendar_forward_event","version":"2.0","source":"BuiltIn"},{"id":"calendar_manage_reminder","version":"2.0","source":"BuiltIn"},{"id":"calendar_delete_event","version":"1.0","source":"BuiltIn"},{"id":"calendar_propose_new_time","version":"2.0","source":"BuiltIn"},{"id":"calendar_list_calendars","version":"1.0","source":"BuiltIn"},{"id":"calendar_manage_attachments","version":"2.0","source":"BuiltIn"},{"id":"calendar_consolidate_poll","version":"1.0","source":"BuiltIn"},{"id":"calendar_get_poll","version":"1.0","source":"BuiltIn"},{"id":"calendar_create_poll","version":"1.0","source":"BuiltIn"}],"matchedFunctionCandidates":[],"functionsSelectedForInvocation":[],"functionExecutions":[]},"agentMetaData":{"agentId":"","agentVersion":"","conversationId":"","requestId":"","agentName":"","icon":""},"connectedAgents":{"enabledConnectedAgents":[],"connectedAgentsExcecutionInfo":[]},"editorialAnswers":{"executionInfoItems":[]}}
Ashlesha Pawar (Tata Consultancy Services Limited) 395 Reputation points Microsoft External Staff

2026-09-11T13:31:44.3933333+00:00

Thanaphop Parinyarat Thank you for the detailed information and for performing the additional validation steps. Based on the observations shared, including successful OAuth authorization/token issuance and the absence of MCP endpoint calls, this does not appear to be a straightforward connector configuration issue from the information available so far.

We will engage the engineering team internally to review this scenario and determine whether there are any known platform-side considerations related to connector initialization, tool discovery, or token handling that could explain the behavior. Once we receive guidance from the engineering team, we will update this thread with our findings.

Your answer

Ashlesha Pawar (Tata Consultancy Services Limited) 395 Reputation points Microsoft External Staff

2026-09-11T06:28:56.9266667+00:00

The successful /authorize, /token, and refresh operations on your authorization server do not necessarily mean Microsoft 365 Copilot successfully stored/retrieved the token or proceeded to invoke the MCP endpoint.

The flow should be considered as:

authorize → token issued → Microsoft token store/runtime → MCP invocation

Since you see no MCP access request, the failure may be occurring between token issuance and the resource call.

Please verify:

Enable Copilot Developer Mode and capture the debug information card. Microsoft documents this as the primary way to expose the underlying authentication error behind generic messages such as token store error, connector unavailable.

Ensure the MCP reference_id exactly matches the OAuth configuration ID in Teams Developer Portal.

Ensure the OAuth configuration Base URL exactly matches the MCP server URL, including path/port and trailing-slash consistency.

Set Restrict usage by app to Any Teams app. Microsoft notes that binding an MCP OAuth configuration to an existing Teams app ID can provision successfully but fail at runtime in Microsoft 365 Copilot.

Confirm the affected tenant is allowed by the organization restriction.

Verify the redirect URI is exactly: https://teams.microsoft.com/api/platform/v1.0/oAuthRedirect

Ensure the token endpoint responds directly with HTTP 200; Microsoft documents that a 307 Temporary Redirect is unsupported.

Validate OAuth metadata, PKCE, protected-resource metadata, and the RFC 8707 resource value for exact/consistent URI handling.

These checks can help determine whether the failure is occurring during token-store/runtime processing before Copilot reaches the MCP endpoint.
Ashlesha Pawar (Tata Consultancy Services Limited) 395 Reputation points Microsoft External Staff

2026-09-11T13:31:44.3933333+00:00

Thanaphop Parinyarat Thank you for the detailed information and for performing the additional validation steps. Based on the observations shared, including successful OAuth authorization/token issuance and the absence of MCP endpoint calls, this does not appear to be a straightforward connector configuration issue from the information available so far.

We will engage the engineering team internally to review this scenario and determine whether there are any known platform-side considerations related to connector initialization, tool discovery, or token handling that could explain the behavior. Once we receive guidance from the engineering team, we will update this thread with our findings.