MCP server tools unavailable on one shot prompts

[SchwartzKamel]

Short summary

MCP server tools unavailable on first prompt of new session; require follow-up message to appear

Affected version or release

1.0.71-2

Installation context

Slack MCP server configured via ~/.copilot/mcp-config.json (type: http, url: https://mcp.slack.com/mcp, OAuth public client). Likely affects any remote/HTTP MCP server, observed specifically with Slack MCP.

What happened?

On the first user prompt in a brand-new session, tools contributed by a correctly configured remote MCP server (Slack MCP) were completely absent from the assistant's available tool list. Running extensions_manage(list) / extensions_reload also reported "0 extensions running / No extensions found," which is misleading since this MCP server isn't part of the .github/extensions system, so there was no way to detect or force-refresh the connection from within the turn.

Only after the user sent a second, unrelated follow-up prompt did a "tools_changed_notice" system event fire, exposing the Slack-MCP-* tools (slack_send_message, slack_read_channel, etc.). The assistant had no mechanism to trigger this itself on turn one.

Separately, later in the same session, an unprompted "Tools no longer available: Slack-MCP-slack_send_message" notice appeared with no user action taken, showing tools can also silently disappear mid-session.

Steps to reproduce

1. Configure a remote/HTTP MCP server (e.g., Slack MCP) with OAuth in mcp-config.json.
2. Start a brand-new chat session.
3. On the very first prompt, ask the assistant to use a tool from that MCP server.
4. Observe the tool is missing from the available tool list (extensions list also shows 0 running).
5. Send any second, even unrelated, follow-up prompt.
6. Observe a "tools_changed_notice" fires and the MCP tools become available.

Expected behavior

Tools from a correctly configured MCP server should be available on the first prompt of a session without requiring a throwaway follow-up message to "wake up" the tool list. If a connection/handshake delay is unavoidable, the assistant/runtime should detect and wait or retry within the same turn instead of requiring user intervention.

Additional context

• ~/.copilot/mcp-config.json:
  {
  "mcpServers": {
  "Slack MCP": {
  "tools": ["*"],
  "type": "http",
  "url": "https://mcp.slack.com/mcp",
  "oauthClientId": "<SLACK_OAUTH_TOKEN>",
  "oauthPublicClient": true
  }
  }
  }
• extensions_manage(list) and extensions_reload both reported 0 extensions before the Slack tools appeared - this API doesn't seem to surface remote MCP server status.
• Tool availability also churned later in-session (tool silently removed), suggesting a broader MCP connection lifecycle issue beyond just cold start.
• Model: All available models (tested with GPT 5.6 Luna, GPT 5.6 Tera, Haiku 4.5, Sonnet 5), GitHub Copilot CLI/App v1.0.71-2, Windows