[Bugs] ADO MCP even though connected, frequently fails.

[rhalgr]

Mood: 😔
Category: Bugs

ADO MCP even though connected, frequently fails. GitHub MCP even though says it cannot auth, actually works. Both using HTTP setup.

---

Field	Value
App version	0.2.7
OS	Windows 10.0.26200
Theme	Fox
Path	/chat
Tenure	Day 1

[rhalgr]

As a workaround, I can have the app fire up copilot CLI in a powershell command and use that to do the exact same thing.

[rhalgr]

Observed behavior

ADO MCP: Shows as connected in the MCP panel, but tool calls intermittently fail to reach the server. During this session, ADO tools were unavailable at session start and only became available ~75 minutes in (tools_changed_notice appeared mid-conversation). No user action triggered reconnection - it happened silently.

GitHub MCP: Panel shows auth/connection warning (suggesting it shouldn't work), but all GitHub MCP calls (search_code, get_file_contents) succeed without issue.

Environment

• App version: 1.0.49
• OS: Windows 10.0.26200
• MCP transport: HTTP (both ADO and GitHub)
• ADO org: BankFabricGit (dev.azure.com)

Reproduction pattern

1. Open a project session
2. ADO MCP tools may or may not be available at start
3. No clear trigger for when they reconnect
4. GitHub MCP works throughout despite status indicator saying otherwise

What would help diagnosis

• Are there MCP connection logs we can capture?

[rhalgr]

Update: ADO MCP tools disappeared again ~2 minutes after the tools_changed_notice confirmed availability. Connection is unstable/cycling, not a one-time startup delay.

[rhalgr]

AI-side visibility gap (observed 2026-05-21)

The model has zero awareness of MCP server state. When tools aren't available:

• No connecting..., failed, or retrying status is surfaced to the model
• Tools simply don't appear in the available set - indistinguishable from not configured
• The model confidently tells the user I don't have ADO tools when the truth is they aren't ready yet
• No mechanism to request a reconnect or report the absence back to the runtime

Impact: The user gets incorrect information (I can't do this) instead of accurate information (this isn't available yet, it may still be connecting). The model can't self-correct because it has no signal to distinguish between missing, pending, failed, or cycling.

Suggestion: Surface MCP connection state as a system-level context visible to the model (e.g., mcp_status: {ado: 'connecting', github: 'ready'}), so it can give accurate answers and potentially trigger a retry.

[rhalgr]

Connection cycling observed again (2026-05-21)

Timeline today (all Eastern):

Time	Event
07:20	Chat opened, ADO tools unavailable
07:21	tools_changed_notice - ADO connected (~1 min startup)
08:26	ADO connection cycled (dropped and reconnected quickly, another tools_changed_notice)
10:04	ADO tools gone - confirmed via tool call returning Tool does not exist. Project session also reporting MCP unavailable.
10:06	tools_changed_notice - ADO reconnected (~2 min outage)

Pattern: Connection held for ~100 minutes, dropped, auto-reconnected after ~2 min. Both chat and project sessions lost access simultaneously (shared connection). No user action triggered the reconnect - it happened on its own.

This supports the theory that the app's HTTP MCP client has no keep-alive/heartbeat mechanism, and reconnection is passive rather than actively retried.

[rhalgr]

Feature asks to mitigate this

Beyond fixing the root cause (connection cycling), any of these would significantly reduce the pain:

1. UI connection state indicator - Show reconnecting... or disconnected on the MCP server badge so the user knows before they ask the agent to do something that will fail silently.

2. Surface state to the agent (from earlier comment) - A system-level mcp_status context so the agent can say ADO is reconnecting, try again in a moment instead of confidently declaring I don't have access to ADO tools.

3. Manual reconnect trigger - A button or command (even just /mcp reconnect ado) so the user or agent can force a retry rather than passively waiting 2-75 minutes for it to come back on its own.

Right now the failure is silent on both sides - the user doesn't see it, the agent doesn't know it, and neither can fix it.

[rhalgr]

Correction to previous comment: Referenced a badge that doesn't exist in the current UI. Point #1 should read:

Show MCP connection state somewhere visible in the UI (status bar, sidebar indicator, or inline when a tool call would fail) so the user knows the connection is down before asking the agent to use it.

[rhalgr]

Repro clue: chat session triggers reconnection, project session does not (2026-05-21)

Observed repeatedly today: when ADO MCP drops, the affected project session cannot recover by retrying. The agent reports tools not available indefinitely regardless of how many times you ask it to retry. However, messaging a separate chat session consistently triggers reconnection within seconds (a tools_changed_notice fires almost immediately after sending the message).

Steps:

1. ADO MCP connection drops (both chat and project session lose tools simultaneously)
2. In the project session, ask the agent to retry the ADO call - fails indefinitely, no reconnection
3. Switch to a general chat session and ask it to check ADO - tools_changed_notice fires within seconds, tools are back
4. Project session now also has tools again (shared connection)

Implication: Something in the chat session's turn-processing code path triggers an MCP reconnection attempt that the project session's retry path does not. This isn't coincidence - it reproduced 3+ times today with the same pattern. The project session appears to re-check a cached/stale tool list without ever hitting the reconnection logic.