Hermes declares URL-mode elicitation and declines every URL-mode request

Kind: gap · Status: current · Last verified: 2026-11-09 · Clients: hermes-agent · Revisions: 2025-11-25

In mcp 2.3.0, ClientSession._build_capabilities declares elicitation as ElicitationCapability(form=FormElicitationCapability(), url=UrlElicitationCapability()) whenever the caller passed an elicitation callback. A caller cannot declare form mode alone.

Hermes passes a callback by default, since elicitation.enabled defaults to true. The callback's first check is for URL mode, and it declines with a log line saying URL-mode elicitation is not implemented. The probe run against hermes-agent 0.23.0 recorded the initialize request with "elicitation":{"form":{},"url":{}}. A server that trusts the declaration and sends a URL-mode request for an OAuth or payment step gets a decline every time.

Form mode is declared and handled, but only as a consent prompt. The user sees the message and a summary of the requested fields and answers accept, decline or cancel. Accept returns content={}, so a server that asked for values receives none.

Both behaviours were already present at a24c12d1. The August registry entry recorded URL mode as full, with a browser opened at the URL, and form mode as full. Neither was correct at that commit.

The SDK side matches the roots.listChanged problem in fast-agent-never-sends-roots-list-changed: the SDK declares a capability on the strength of a callback being present, and the caller has no way to narrow it.

Sources