Custom federated MCP connector calls server/discover but never tools/list

Question

Custom federated MCP connector calls server/discover but never tools/list

Mohamed Safiyullah 0

A custom federated connector (Copilot > Connectors > Create a new connector > Connect to MCP server, No Auth, public HTTPS endpoint) connects and calls server/discover, but never calls tools/list or tools/call. No tools are registered, so the connector is unusable in Copilot Chat and enterprise search for it returns nothing.

Protocol revision 2026-07-28. The connector is enabled, rolled out to everyone, and connected as a source in Copilot Chat settings.

Copilot's request, captured on the server:

{"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientInfo":{"name":"Sydney","version":"1.0.0"},
  "io.modelcontextprotocol/clientCapabilities":{}}},"id":1,"jsonrpc":"2.0"}

Our response, HTTP 200, a schema-exact DiscoverResult:

{"resultType":"complete",
 "supportedVersions":["2026-07-28","2025-11-25","2025-06-18"],
 "capabilities":{"tools":{"listChanged":false}},
 "instructions":"...","ttlMs":3600000,"cacheScope":"public",
 "_meta":{"io.modelcontextprotocol/serverInfo":{"name":"...","version":"1.0.0"}}}

Then nothing. One server/discover after registration and no follow-up. An earlier registration polled it every 2 to 3 minutes indefinitely, and still never called tools/list.

Already ruled out: protocol version rejection (this was real at first, now fixed and verified); server/discover not implemented; empty capabilities.tools; no search or fetch shaped tools (search and fetch added, all tools carry readOnlyHint); the .well-known OAuth paths not returning 404; Allowed agent types and User access settings; licensing (support confirmed the entitlement is valid, and Graph shows M365_COPILOT_CONNECTORS Enabled for the signed-in user); stale registration (the connector was deleted and recreated against the working server, with no change).

Control case: the same endpoint on the same protocol revision works end to end with a different MCP client. It calls server/discover, then tools/call, and returns correct results.

Questions:

What causes the federated connector runtime to complete server/discover and never call tools/list?

Is there an additional requirement on DiscoverResult, or a validation step between registering a connector and tool enumeration, that is not documented?

Can an admin see anywhere why a connector registered no tools? The admin centre shows the connector as healthy, which gives no signal that discovery produced nothing.

Prasad-MSFT 10,546 Reputation points Microsoft External Staff Moderator

2026-08-26T06:42:37.6866667+00:00
server/discover succeeding only proves the endpoint is reachable and the protocol version is accepted. It does not guarantee tool enumeration will occur.

Microsoft documentation indicates that tool discovery can be gated by additional runtime validation and discovery checks before tools/list is invoked. If discovery fails validation internally, tools may never be populated even though the connector appears healthy.

Since you've already ruled out protocol version, auth, licensing, OAuth metadata, and tool definitions, please look at:

Whether the DiscoverResult is missing a field that the federated connector runtime expects but doesn't document.

Whether Microsoft's connector runtime is performing an internal validation step between server/discover and tools/list.

Also worth enabling developer/debug tooling where available and checking whether the runtime reports validation errors or "no tools listed" diagnostics. Microsoft specifically calls out runtime validation and dynamic tool discovery as potential causes when tools never appear.

Given that the same endpoint works with another MCP client and the connector never progresses past server/discover, my suspicion would be an undisclosed validation step or a federated-connector runtime defect rather than a protocol-compliance issue on your server.

Your answer

Prasad-MSFT 10,546 Reputation points Microsoft External Staff Moderator

2026-08-26T06:42:37.6866667+00:00

server/discover succeeding only proves the endpoint is reachable and the protocol version is accepted. It does not guarantee tool enumeration will occur.

Microsoft documentation indicates that tool discovery can be gated by additional runtime validation and discovery checks before tools/list is invoked. If discovery fails validation internally, tools may never be populated even though the connector appears healthy.

Since you've already ruled out protocol version, auth, licensing, OAuth metadata, and tool definitions, please look at:

Whether the DiscoverResult is missing a field that the federated connector runtime expects but doesn't document.

Whether Microsoft's connector runtime is performing an internal validation step between server/discover and tools/list.

Also worth enabling developer/debug tooling where available and checking whether the runtime reports validation errors or "no tools listed" diagnostics. Microsoft specifically calls out runtime validation and dynamic tool discovery as potential causes when tools never appear.

Given that the same endpoint works with another MCP client and the connector never progresses past server/discover, my suspicion would be an undisclosed validation step or a federated-connector runtime defect rather than a protocol-compliance issue on your server.