MCP server pill disappears from composer after sending a message, and tool behavior becomes inconsistent

ChatGPT Bugs
,
1

Summary:
When I attach an MCP server to the chat box (via the tools/attach menu), it shows as a pill/tag in the composer confirming it’s active. After sending a message, that pill disappears — the server is no longer shown as attached, and has to be manually re-attached before the next message. Separately, the server’s behavior is inconsistent: sometimes it works exactly as expected (calls the right tool, asks for all required fields at once), and other times in the same session it fails to call the tool that renders our widget, or asks for required fields one at a time instead of all at once, despite the prompt explicitly instructing it to ask for everything up front.

Environment:
ChatGPT surface: Web app
Browser: Chrome
ChatGPT plan: Free
Connector type: Remote MCP server, attached via the chat box tools/attach menu
MCP transport: Streamable HTTP (single /mcp endpoint)
MCP server framework: Spring AI MCP Server (async), spec version 1.0.0
MCP protocol mode: STATELESS
Server hosting: Behind an API gateway (WSO2 API Manager)
Date observed: Ongoing, all week (week of July 6–10, 2026)

Steps to Reproduce:

  1. Attach the MCP server via the tools/attach menu in the composer — the server name appears as a pill.
  2. Send a message that uses the server.
  3. Check the composer again — the pill is gone.
  4. Re-attach and repeat over several messages — behavior varies: sometimes the tool call and field-batching work correctly, other times the widget-render tool isn’t called, or fields are requested one at a time instead of all at once.

Expected Behavior:
The pill should persist for the conversation, and tool-calling/instruction-following should be consistent from message to message.

Actual Behavior:
The pill disappears after every message. Tool-calling and instruction-following are inconsistent — correct in some messages, wrong in others, with no clear pattern.

Additional Context:
Inconsistent, not reliably reproducible on demand — this is the core difficulty in describing it. No error shown in the UI when the pill disappears. Can provide server-side DEBUG logs (io.modelcontextprotocol, org.springframework.ai.mcp) comparing a working vs. failing request if useful.

2

Im seeing the same for me, before when it was still called App, the app stayed “Connected”, now its fire and forget?