Scalar/list elicitation schemas emit a non-suppressible top-level `title` (internal model name)

[whitford-olmst]

Problem

With a scalar or list response_type, ctx.elicit() wraps the value in an object schema whose top-level title is FastMCP's internal wrapper name, "ScalarElicitationType", with no supported way to suppress it. (#3911 added control over the property-level title/description, but the object-level title remains.)

Example (fastmcp 3.4.2, mcp 1.28.0)

from fastmcp.server.elicitation import parse_elicit_response_type
parse_elicit_response_type(["yes", "no"]).schema
# {
#   "type": "object",
#   "properties": {"value": {"enum": ["yes","no"], "title": "Value", "type": "string"}},
#   "required": ["value"],
#   "title": "ScalarElicitationType",   # internal model name, on the wire
# }

Expected vs. actual

• Expected: the wrapper schema doesn't put FastMCP's internal model name on the wire (or lets it be suppressed).
• Actual: every scalar/list elicitation emits "title": "ScalarElicitationType".

Non-obvious insight (from research)

This breaks clients that parse requestedSchema strictly: Codex (CLI + Desktop) declares its schema with serde deny_unknown_fields and rejects every FastMCP elicitation with unknown field 'title', so the form never renders (openai/codex#31163). I confirmed empirically that an otherwise-identical title-less schema renders and is accepted on the same client. The MCP requestedSchema (2025-11-25) sets no additionalProperties: false and title is valid JSON Schema, so this is arguably also a client bug — but since the emitted title is a valueless internal name, dropping it fixes the interop failure with no downside.

[awhitford]

Root cause

get_elicitation_schema() builds the wire schema for the internal ScalarElicitationType wrapper, and Pydantic emits that class name as a top-level title. It's a pure implementation detail that shouldn't be on the wire, and strict clients (Codex's deny_unknown_fields) reject the unknown top-level field. The scalar and single-select forms hit it; the raw multi-select form ([["a", "b"]]) is built by hand and already omits it.

Proposed fix

Drop the top-level title in get_elicitation_schema() only when the response type is the ScalarElicitationType wrapper, so property-level titles and user-supplied models are untouched. Small, well-scoped change with a test that fails without it.

Could a maintainer assign this issue to me? Happy to open the PR once assigned.

[syf2211]

Opened # with a minimal fix: strip the top-level wrapper title in get_elicitation_schema() for ScalarElicitationType only. Happy to adjust if you'd prefer assignment before review — please assign #4477 if this approach looks good.