feat: Support for URL mode elicitation

[iturgeon]

Summary

Adds support for URL mode elicitation. Updates advertised compatibility, adds some UI functionality, and tests for the changes.

NOTE: looks like there's another attempt at this: #1108
Maintainers, LMK if effort is best spent working with the other PR or what.

Note: Inspector V2 is under development to address architectural and UX improvements. During this time, V1 contributions should focus on bug fixes and MCP spec compliance. See CONTRIBUTING.md for more details.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Build/CI improvements

Changes Made

• Updates the MCP client's advertised compatibility to include the newer object structure that indicates url mode elicitation support.
• Adds detection of URL mode elicitation 'errors' and raises them to the user.
• Adds support for accept, deny, and cancel responses.
• Adds URL mode Elicitation UI to present the URL to the user with buttons to open in a new tab in addition to accept, deny, and cancel responses.

Spec Conformance Review

Based on the MCP Elicitation Specification (2025-11-25).

Conformant

1. Capabilities declaration - Declares elicitation: { form: {}, url: {} } during initialization
2. elicitation/create handling - The onElicitationRequest handler extracts mode, message, requestedSchema, url, and elicitationId from the request. Defaults mode to "form" when omitted, satisfying the backwards compatibility.
3. Response actions - All 3 actions (accept, decline, cancel) implemented
4. Form mode validation - Schema validation via AJV, required field checks, and email format validation are present.
5. URL HTTPS enforcement - Only HTTPS URLs are permitted.
6. URL shown to user before navigation - The full URL is displayed to the user before any navigation occurs.
7. URL not opened without consent
8. URL opened securely - Uses window.open(url, "_blank", "noopener,noreferrer")
9. Domain highlighted
10. Completion notification - ElicitationCompleteNotificationSchema is registered as a notification handler.
11. URLElicitationRequiredError (-32042) - extracts the data.elicitations array and presents URL mode elicitation UI to the user.
12. Type safety for URL mode fields - ElicitationRequestData type is a discriminated union: url and elicitationId are required when mode: "url", and requestedSchema is only available when mode: "form".
13. Clear target server identification - The UI clearly labels requests as "URL Elicitation Request" with the server's message, target domain, full URL, and elicitation ID.
14. Decline and cancel options - Both form and URL mode provide explicit Decline and Cancel buttons.

Not Implemented

1. Punycode/suspicious URI warnings (SHOULD) - No detection or warning for ambiguous URIs containing Punycode or homograph attacks.
2. URLElicitationRequiredError retry mechanism - When a -32042 error is caught, the elicitation is displayed to the user but there is no mechanism to automatically or manually retry the original tools/call after the elicitation completes.
   The spec's flow diagram shows this as optional ("Retry tools/call (optional)"), and the resolve callback on error-originated elicitations is a no-op. The normal elicitation/create flow (server-initiated) works correctly end-to-end.
3. Rate limiting (SHOULD) - No rate limiting on elicitation requests from servers.

Related Issues

Testing

Tested manually with a custom MCP server that supports URL mode Elicitation. Also ran jest and playwright tests.

• Tested in UI mode
• Tested in CLI mode
• Tested with STDIO transport
• Tested with SSE transport
• Tested with Streamable HTTP transport
• Added/updated automated tests
• Manual testing performed

Test Results and/or Instructions

Testing with an MCP server that supports URL mode Elicitation is a challenge, not many support it, let alone advertise support for it. I was testing with a private MCP server that does.

Checklist

• Code follows the style guidelines (ran npm run prettier-fix)
• Self-review completed
• Code is commented where necessary
• Documentation updated (README, comments, etc.)

Breaking Changes

MCP Servers not built to handle the new compatibility structure changing from elicitation: {} to elicitation: { form: {}, url: {} } could have unforeseen issues, but perhaps that's unlikely to cause an issue.

Additional Context

I think it would be nice to add an option to change how this client advertises it's capabilities for testing purposes, to switch between different stages of the spec and manually turn them on and off. That's not included here.