Client bugs: elicitation scalar return, resource dict return, raise_on_error+task, Client.new() shared state, prompt error message

[strawgate]

Five client-side bugs found during a systematic audit. All confirmed with real code, no mocks.

1. Elicitation handler returning scalar T fails for str/int/float/bool

The ElicitationHandler type signature says the return type is T | dict | ElicitResult[T]. For ctx.elicit("msg", str), returning "Alice" (a valid T) crashes with "Elicitation responses must be serializable as a JSON object (dict)."

@mcp.tool
async def ask(ctx: Context) -> str:
    result = await ctx.elicit("Name?", response_type=str)
    return result.data

async def handler(msg, rtype, params, ctx):
    return "Alice"  # valid T per type signature — crashes

Root cause: create_elicitation_callback in client/elicitation.py calls to_jsonable_python(result.content) and rejects non-dict results. For scalar types, the internal ScalarElicitationType wrapper is never auto-unwrapped on the return path.

2. Resource returning dict/int/None crashes despite docstring promising auto-serialization

@mcp.resource("data://info")
def info(): return {"key": "value"}
# McpError: contents must be str, bytes, or list[ResourceContent], got dict

FunctionResource docstring says "other types will be converted to JSON" but ResourceResult.__init__ only accepts str | bytes | list[ResourceContent].

3. raise_on_error=True silently ignored when task=True

task = await client.call_tool("fail", task=True, raise_on_error=True)
result = await task
# result.is_error == True — no exception raised

The task=True branch in call_tool doesn't forward raise_on_error to _call_tool_as_task or _parse_call_tool_result.

4. Client.new() shares mutable task state with original

c1 = Client(mcp)
c2 = c1.new()
c1._submitted_task_ids.add("task-abc")
"task-abc" in c2._submitted_task_ids  # True — shared reference

copy.copy() is shallow. _task_registry (dict) and _submitted_task_ids (set) are shared references. The docstring says "fresh session state" but task tracking state isn't fresh.

5. Prompt error drops original exception message

Tool errors include the cause: "Error calling tool 'name': original message". Prompt errors drop it: "Error rendering prompt name." (no cause).

@mcp.prompt()
def bad():
    raise ValueError("CHECK CONFIG AT /etc/app.conf")
# Client sees: "Error rendering prompt bad." — original message lost

Root cause: function_prompt.py:337 wraps as PromptError(f"Error rendering prompt {self.name}.") without including {e}.

🤖 Generated with Claude Code

[marvin-context-protocol]

Claude finished @strawgate's task in 4m 14s —— View job

---

Triage: Five Client-Side Bugs

All five bugs are confirmed with code analysis and test verification. Four of the five are straightforward fixes (1-3 lines each). Bug 3 needs slightly more design thought around the task/raise_on_error interaction.

Findings

Bug 1: Elicitation scalar return — Confirmed ✅

Root cause: create_elicitation_callback in src/fastmcp/client/elicitation.py:62-67 calls to_jsonable_python(result.content) and rejects anything that isn't a dict. When the server sends response_type=str, the schema uses a ScalarElicitationType wrapper, so on the server side the response is unwrapped from {"value": "Alice"} back to "Alice". But the client-side callback only knows about the raw type str (reconstructed via json_schema_to_type), so when the handler returns "Alice", to_jsonable_python("Alice") produces "Alice" (a str), not a dict, and the check fails.

Fix: In create_elicitation_callback, wrap scalar return values in {"value": result} before the dict check, mirroring the server's ScalarElicitationType wrapper. Specifically, after line 62, if content is not a dict and response_type was reconstructed from a schema that wraps in ScalarElicitationType (i.e., the schema has properties.value), wrap it: content = {"value": content}.

Bug 2: Resource returning dict — Confirmed ✅

Root cause: Resource.convert_result() at src/fastmcp/resources/base.py:332-333 falls through to ResourceResult(raw_value) for non-str/bytes values. ResourceResult.__init__ only accepts str | bytes | list[ResourceContent], so a dict raises TypeError. The FunctionResource docstring (line 79) promises "other types will be converted to JSON" but convert_result doesn't handle this case.

Fix: In convert_result, replace the catch-all return ResourceResult(raw_value) with wrapping in ResourceContent first:

return ResourceResult([ResourceContent(raw_value, mime_type=self.mime_type, meta=self.meta)])

ResourceContent.__init__ already handles dicts/lists/BaseModels via pydantic_core.to_json() (line 88 in base.py).

Bug 3: raise_on_error + task=True — Confirmed ✅

Root cause: call_tool() at src/fastmcp/client/mixins/tools.py:275-278 — the task=True branch calls _call_tool_as_task() without forwarding raise_on_error. Two sub-issues:

1. Graceful degradation path (line 351): _parse_call_tool_result is called without raise_on_error, defaulting to False.
2. Immediate result path in ToolTask.result() (tasks.py:349-351): returns self._immediate_result directly without checking for errors.

The background task path (tasks.py:366-372) hardcodes raise_on_error=True, which is inconsistent — it should respect the caller's preference.

Fix: _call_tool_as_task needs a raise_on_error parameter. For graceful degradation, forward it to _parse_call_tool_result. For background tasks, store it on the ToolTask and use it in result() instead of hardcoding True. The ToolTask constructor should accept an optional raise_on_error parameter.

Bug 4: Client.new() shared state — Confirmed ✅

Root cause: Client.new() at src/fastmcp/client/client.py:434 uses copy.copy(self) which is shallow. _submitted_task_ids (set, line 348) and _task_registry (dict, line 352) are mutable containers that end up shared between original and copy.

Fix: After copy.copy(self), explicitly reset the mutable task state:

new_client._submitted_task_ids = set()
new_client._task_registry = {}

This aligns with the docstring's promise of "fresh session state."

Bug 5: Prompt error drops original message — Confirmed ✅

Root cause: FunctionPrompt._render() at src/fastmcp/prompts/function_prompt.py:337 catches all exceptions and wraps them as PromptError(f"Error rendering prompt {self.name}.") — dropping {e}. This is different from the server-level handler at server.py:1435-1436 which does include {e} (when _mask_error_details is False). However, since PromptError is a subclass of FastMCPError, the server's except (FastMCPError, McpError): raise (line 1429-1431) re-raises the already-wrapped error from _render() without ever reaching the server's own error formatting.

Fix: Change _render() line 337 to include the original error:

raise PromptError(f"Error rendering prompt {self.name}: {e}") from e

Note: The server already has its own _mask_error_details logic for the except Exception path, but _render() converts all exceptions to FastMCPError before the server sees them, bypassing the masking logic entirely. A cleaner fix would be to not catch exceptions in _render() and let the server handle them — but that's a larger refactor. The minimal fix is to include {e}.

Verification

I wrote and ran tests for all 5 bugs. All 7 tests failed as expected, confirming the bugs:

tests/test_issue_3856_verify.py::test_elicitation_scalar_str_return      FAILED
tests/test_issue_3856_verify.py::test_elicitation_scalar_int_return      FAILED
tests/test_issue_3856_verify.py::test_resource_returning_dict            FAILED
tests/test_issue_3856_verify.py::test_resource_returning_int             FAILED
tests/test_issue_3856_verify.py::test_raise_on_error_with_task           FAILED
tests/test_issue_3856_verify.py::test_client_new_shared_task_state       FAILED
tests/test_issue_3856_verify.py::test_prompt_error_includes_original_message FAILED

Key error messages:

• Bug 1: ToolError: Error calling tool 'ask': Elicitation responses must be serializable as a JSON object (dict). Received: 'Alice'
• Bug 2: McpError: Error reading resource 'data://info': contents must be str, bytes, or list[ResourceContent], got dict
• Bug 4: AssertionError: _submitted_task_ids is shared between original and .new() client
• Bug 5: pytest.raises looking for "CHECK CONFIG" in error message — not found (message is just "Error rendering prompt bad.")

Recommendation

All five bugs are valid and should be fixed. I'd recommend splitting into two PRs for clean review:

PR 1 — Simple fixes (bugs 2, 4, 5): These are 1-3 line changes with no design decisions needed.

PR 2 — Behavioral fixes (bugs 1, 3): These require slightly more thought about API design. Bug 1 needs careful handling of the scalar wrapping convention between server and client. Bug 3 needs a decision about how raise_on_error should interact with ToolTask — both the graceful degradation path and the background task path.

That said, all five can go in a single PR if preferred — none are risky.

Detailed Action Plan

Bug 5 — Prompt error message (simplest, do first)

File: src/fastmcp/prompts/function_prompt.py
Line 337: Change:

raise PromptError(f"Error rendering prompt {self.name}.") from e

to:

raise PromptError(f"Error rendering prompt {self.name}: {e}") from e

Bug 4 — Client.new() shared state

File: src/fastmcp/client/client.py
After line 438 (after new_client._session_state = ClientSessionState()), add:

new_client._submitted_task_ids = set()
new_client._task_registry = {}

These should be reset unconditionally (not just for non-Stdio transports), since they are per-client mutable state.

Bug 2 — Resource dict return

File: src/fastmcp/resources/base.py
Line 332-333: Replace:

# ResourceResult.__init__ handles all other normalization
return ResourceResult(raw_value)

with:

# Other types (dict, list, BaseModel, etc.) → wrap in ResourceContent
# which handles JSON serialization automatically
return ResourceResult(
    [ResourceContent(raw_value, mime_type=self.mime_type, meta=self.meta)]
)

Bug 1 — Elicitation scalar return

File: src/fastmcp/client/elicitation.py
Lines 62-67: The core issue is that for scalar types, the server sends a JSON schema with {"type": "object", "properties": {"value": ...}} (from ScalarElicitationType), and the server unwraps {"value": X} → X on the response. But the client callback reconstructs the type as str/int/etc. and doesn't know it needs to wrap scalar returns as {"value": X}.

Fix approach: After content = to_jsonable_python(result.content), check if the schema indicates scalar wrapping and wrap accordingly:

content = to_jsonable_python(result.content)
if not isinstance(content, dict | None):
    # Scalar type — wrap in the format expected by the protocol
    content = {"value": content}

This mirrors what the server does with ScalarElicitationType — the MCP protocol requires elicitation responses to be JSON objects, so wrapping is the correct behavior.

Bug 3 — raise_on_error + task=True

This needs changes in two files:

1. src/fastmcp/client/mixins/tools.py: Add raise_on_error param to _call_tool_as_task, forward from call_tool. In the graceful degradation path (line 351), pass raise_on_error to _parse_call_tool_result.

2. src/fastmcp/client/tasks.py: Add raise_on_error to ToolTask.__init__, store it. In ToolTask.result(), use the stored value instead of hardcoding True on lines 367, 372, 385.

Related Files

File	Relevance	Bug
src/fastmcp/client/elicitation.py	Elicitation callback creation with scalar type handling	#1
src/fastmcp/server/elicitation.py	Server-side ScalarElicitationType wrapping — client must mirror this	#1
src/fastmcp/resources/base.py	Resource.convert_result() and ResourceResult._normalize_contents()	#2
src/fastmcp/client/mixins/tools.py	call_tool() and _call_tool_as_task() — raise_on_error not forwarded	#3
src/fastmcp/client/tasks.py	ToolTask.result() — hardcodes raise_on_error=True	#3
src/fastmcp/client/client.py	Client.new() — shallow copy of mutable state	#4
src/fastmcp/prompts/function_prompt.py	FunctionPrompt._render() — drops exception message	#5

---

Marvin Context Protocol | Type /marvin to interact further

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[marvin-context-protocol]

Thanks for the report. This issue goes beyond what our contributor guidelines ask for — we just need a short problem description and an MRE. Please see our contributing guidelines and condense this issue. We'll triage it once it's trimmed down.