feat(api): support elicitation from tool calls

[Cali0707]

This PR adds a first pass at adding elicitation support, so that toolset authors can use elicitation flows within their tools.

Note that I have not used this in any tools yet, just working to land support first here.

Fixes #801

[matzew]

should we document this a bit? Like others, e.g. Tool ?

[matzew]

overall it does LGTM

[manusa]

The TODO should be more actionable for tool authors. When session.Elicit() fails because the client doesn't support elicitation, the go-sdk returns a JSON-RPC error with code -32602 and message "client does not support elicitation". Tool authors need to know how to distinguish this from other errors so they can implement fallback behavior.

Consider either:

• Documenting the expected error type/code here so callers know what to check
• Wrapping it in a sentinel error (e.g., ErrElicitationNotSupported) that callers can use with errors.Is()

This becomes important as soon as actual tools start using elicitation.

[manusa]

Pull Request Review: #804

Summary

Adds foundational MCP elicitation support: an Elicitor interface in pkg/api/, a sessionElicitor implementation in pkg/mcp/elicit.go that delegates to the go-sdk ServerSession.Elicit(), and wiring into both ToolHandlerParams and PromptHandlerParams. No tools use elicitation yet — this is plumbing only.

The design is clean and follows the existing patterns in the codebase (embedding interfaces in params structs, concrete implementations in pkg/mcp/).

Review Verdict

REQUEST_CHANGES

Findings

Critical Issues (Must Fix)

1. Rebase on main required — The latest main (66106e7c) switched the test infrastructure from mark3labs/mcp-go to the official modelcontextprotocol/go-sdk client. The go-sdk client supports ElicitationHandler in ClientOptions, which enables real end-to-end elicitation integration tests. Please rebase on main.

2. Missing tests — After rebasing, the go-sdk test client can be extended with a WithElicitationHandler(...) option (following the existing WithHTTPHeaders, WithClientInfo patterns in internal/test/mcp.go). This enables behavior-based integration tests that exercise the actual elicitation protocol flow:

   • TestElicitationAccepted — Client accepts with content, tool receives action=accept and provided data
   • TestElicitationDeclined — Client declines, tool receives action=decline
   • TestElicitationWithUnsupportedClient — Client has no handler, tool gets an error from Elicitor.Elicit() and handles it gracefully (no crash, returns fallback)

   These test the observable end-to-end behavior (server → client → response → server) with no mocks of the elicitor itself.

Suggestions (Should Consider)

See inline comments for:

• ElicitResult.Action should document valid values or define constants
• The TODO in elicit.go should be more actionable for tool authors

Security Concerns

None. The elicitation mechanism delegates to the MCP SDK's session handling, and the jsonschema.Schema parameter constrains client responses.

Overall Assessment

The interface design and wiring are solid. The main gap is the rebase needed to align with the current test infrastructure and enable proper integration tests.

[manusa]

LGTM, thx!