Model contradicts its own runtime behavior — claims no HTTP MCP support while actively using it

[vladk2854-max]

Describe the bug

The model (Claude Opus 4.6 via Copilot CLI v1.0.41) makes 50+ successful native HTTP MCP tool calls during a session, then when asked to create a comparison table of AI clients, incorrectly classifies its own runtime as "❌ does not support HTTP MCP — needs stdio proxy". This directly contradicts what it is doing in the same session.

Affected version

1.0.41

Steps to reproduce the behavior

1. Connect Claude Opus 4.6 to an MCP server via HTTP transport (Streamable HTTP)
2. Successfully use MCP tools (li_h, qu_i, fuz_s, etc.) — model calls them natively throughout the session
3. Ask the model to create a comparison table of AI clients and their MCP transport support
4. Model classifies its own runtime (Copilot CLI) as "❌ stdio only — needs proxy" despite actively using HTTP MCP tools in the same conversation

Actual Result: Model outputs Copilot CLI (мы) | ❌ | — | — | ✅ Через stdio-proxy — claiming it does NOT support HTTP transport and requires a proxy, while simultaneously using HTTP transport without a proxy.

Impact: Provides incorrect technical guidance to the user. User had to manually correct the model. This is a self-contradiction — the model's declarative knowledge conflicts with its procedural behavior in the same context window.

Expected behavior

No response

Additional context

Additional Context:

• Sub agents in the session were called and used the proxy to be able to call the mcp tools natively! Looks like this was impact the table.
• The model had made 50+ successful native HTTP MCP tool calls in the same session before producing the incorrect table
• When confronted, the model immediately acknowledged the error and corrected it
• This suggests the model relies on stale training data about "Copilot CLI capabilities" rather than introspecting its actual runtime environment