[Bug]: Jean MCP session controls are very behind what is possible by a user

[alepouna]

Describe the issue

TLDR;
Jean’s MCP session-management tools do not expose or correctly apply the same model, provider, fast mode, effort, and execution mode settings available through the Jean UI.

As a result, AI agents using Jean MCP can create messages whose effective settings differ from the session’s UI selections. The resulting Jean history also omits provider metadata at the message level, making MCP-created prompts appear incomplete or different from human-authored prompts.

Additionally, Jean will pick a random or default provider and model, which can make results differ from expectation or planned usage cost. For example expecting to use Luna Max and using Sol High, burning your session instantly.

---

In detail:

MCP actions are incomplete

The MCP registry currently exposes:

• create_session
• send_chat_message
• get_session_status
• read_session_messages
• related session/worktree actions

However, it does not expose session actions for:

• setting the persistent model
• setting the provider/profile
• setting the backend independently
• setting the effort level
• setting the thinking level
• toggling fast/unfast mode
• discovering model capabilities or supported effort levels

The internal dispatch layer already supports several of these operations, but they are not available through MCP.

Relevant code:

• jean-core/src/jean_mcp_core.rs
• jean-core/src/http_server/dispatch.rs

send_chat_message does not inherit session settings

The MCP send_chat_message schema only accepts:

• model
• executionMode

It does not accept or forward:

• effortLevel
• thinkingLevel
• customProfileName / provider
• backend

When optional values are omitted, the shared send path receives None rather than resolving the session’s persisted selections.

This affects both new and continued sessions.

Fast/unfast support is only implicit

Backend implementations support fast model variants such as:

• gpt-5.5-fast
• gpt-5.6-sol-fast
• claude-opus-4-6[1m]-fast

But MCP has no first-class fast-mode control or capability discovery. Agents must know and provide backend-specific raw model IDs, and model selection is only a one-turn override rather than a persistent session setting.

Effort levels are not available through MCP

The internal chat dispatch supports effort values including:

• minimal
• low
• medium
• high
• xhigh
• max
• ultracode

The MCP schema neither documents nor forwards effortLevel, so MCP-created turns receive no explicit effort setting.

Provider metadata is not represented on ChatMessage

Run metadata stores the provider/profile as custom_profile_name, but the reconstructed ChatMessage only exposes:

• model
• execution mode
• thinking level
• effort level

Provider/profile is not included. Consequently, Jean cannot display the provider used for an individual message, even when it exists in the underlying run metadata.

Human and MCP prompts use the same persistence path, but MCP supplies less metadata

Human and MCP prompts ultimately use the same send_chat_message and run-log persistence path. The apparent difference is caused by:

• the UI explicitly passing current settings;
• the UI adding optimistic messages with metadata;
• MCP only passing a subset of settings;
• MCP returning before the send completes.

This makes MCP messages appear to be stored differently, although the primary issue is incomplete metadata propagation and missing default resolution.

MCP send errors are hidden

MCP send_chat_message is fire-and-forget. It returns status: "started" immediately, while execution errors are only logged and must be discovered through later status polling.

Expected behavior

MCP session operations should provide behavior equivalent to the Jean UI:

1. Agents can select and persist:

   • backend
   • provider/profile
   • model
   • fast/unfast variant
   • effort level
   • thinking level
   • execution mode

2. A message with omitted settings inherits the session’s persisted selections.

3. The same behavior applies to both new and continued/resumed sessions.

4. Every persisted user message exposes the effective:

   • backend
   • provider/profile
   • model
   • fast/unfast state, where applicable
   • effort/thinking level
   • execution mode

5. MCP rejects invalid combinations synchronously where possible, or returns a trackable request ID and exposes the failure through status.

6. The Jean UI displays provider/profile metadata consistently for human- and MCP-created messages.

Proposed acceptance criteria

• Add MCP tools for persistent session model, backend, provider, effort, thinking level, and execution-mode selection, or extend send_chat_message with a clearly documented settings object.
• Add MCP support for fast/unfast model selection using the existing model catalog/capability definitions.
• Resolve omitted per-turn settings from persisted session settings before starting execution.
• Ensure this resolution works for resumed sessions and backend handoffs.
• Persist the effective provider/profile with each run.
• Expose provider/profile in the message/history API where message-level metadata is displayed.
• Ensure MCP-created user messages retain the same model, effort, and execution-mode metadata as UI-created messages.
• Add coverage for:
  • new session + explicit settings;
  • continued session + inherited settings;
  • provider changes;
  • fast/unfast models;
  • effort levels;
  • plan/build/yolo modes;
  • invalid or unsupported combinations;
  • MCP execution failures.

Replication

1. In Jean, configure a session with a non-default provider, model, effort level, and build mode.
2. Send a human-authored prompt and note the displayed metadata.
3. Use MCP send_chat_message with only:

   {
     "sessionId": "...",
     "message": "Inspect the current implementation"
   }

4. Inspect the resulting run and Jean history.
5. Observe that the MCP turn does not reliably inherit the session’s provider, effort, model, or build mode, and that provider metadata is not shown on the resulting message.

How are you running Jean?

App

Operating system

macOS 27 Beta 4

Jean version

v0.1.73

How are you interacting with Jean?

Remotely via another Jean app