Agent App registered as an MCP server: every tools/call fails

Start in api/core/mcp/server/streamable_http.py and trace handle_mcp_request, process_mapping_response, and extract_structured_output for AppMode.AGENT. Compare the Agent App stream in AgentAppRunner._publish_terminal_answer with legacy agent-chat events, then verify tools/call returns the persisted answer, structuredContent, and errors for failed runs without changing existing agent-chat results.

What happens

An Agent App (AppMode.AGENT, the app type backed by an Agent Soul) can be published as an MCP server from the console. tools/list works and returns the tool, but every tools/call fails. The client receives:

{"jsonrpc": "2.0", "id": 1, "error": {"code": -32602, "message": "Agent App only supports streaming mode"}}

Steps to reproduce

1. Create and publish an Agent App.
2. Register it as an MCP server. The console endpoint (api/controllers/console/app/mcp_server.py) has no app-mode filter, so Agent Apps are accepted.
3. Call the tool from any MCP client.

Where it comes from

api/core/mcp/server/streamable_http.py never requests a streaming run for this mode:

streaming=app.mode == AppMode.AGENT_CHAT,

Agent Apps reject blocking generation (api/core/app/apps/agent_app/app_generator.py:89), so the call stops there.

Streaming mode alone is not enough

The stream parser only accumulates agent_thought events. Agent Apps publish their answer on the chat message channel instead (AgentAppRunner._publish_terminal_answer -> publish_text_answer -> QueueLLMChunkEvent), so just enabling streaming produces a successful tool result with an empty answer, which is worse than a visible error. Two details matter for whoever picks this up:

• Agent App agent_message events carry in-progress stream text that can differ from the terminal answer, and their agent_thought rows hold reasoning, so neither channel is the answer.
• Legacy agent-chat sends the same text through both agent_thought and agent_message. Accumulating both by event name doubles every existing agent-chat answer.

extract_structured_output and process_mapping_response in the same file also have no AppMode.AGENT arm: the former returns None (so 2025-06-18 clients get no structuredContent), the latter raises ValueError: Invalid app mode: agent.

Executed evidence

Probing the module's public entry points on main (fea6b6e9), no server needed:

1) process_mapping_response(app, {'answer': ...})
   -> ValueError: Invalid app mode: agent
2) extract_structured_output(app, {'answer': 'hi'}, 'hi')
   -> None
3) answer extracted from a real Agent App stream
   -> answer=''
4) AgentAppGenerator.generate(streaming=False)
   -> AgentAppGeneratorError: Agent App only supports streaming mode
5) tools/call through handle_mcp_request
   -> {'jsonrpc': '2.0', 'id': 1, 'error': {'code': -32602, 'message': 'Agent App only supports streaming mode'}}

Probe 3 feeds the real SSE shape the app emits (agent_message deltas plus a terminal message chunk) and shows the answer would be empty even once streaming is enabled.

Expected behavior

tools/call returns the answer the app itself persists for the message, plus structuredContent for 2025-06-18 clients. A failed run should reach the client as an error rather than as an empty successful result.