feat(elicitation): Add URL elicitation support. SEP-1036

[pbezglasny]

Summary

Implemented support of URL Elicitation SEP-1036. This bring next changes:

• change default elicitation capabilities to form and url
• new subtab for url elicitation, with options to: accept and open url, accept, decline, cancel, and copy url
• show warning if the url is not valid link, has non latin characters or not https protocol
• save notifications/elicitation/complete to notification tab

! This PR does not change behaviour in case URLElicitationRequiredError. The error will only shown in error popup.

Video:

Screen.Recording.2026-01-01.at.20.37.42.mov

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

Code changes:

• Added new component ElicitationUrlRequest
• Updated types for form and url elicitation request data
• Updated ElicitationTab to handle both form and url elicitation requests

Related Issues

Issue: #929

Testing

• 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

Tested with python elicitation server

Test Results and/or Instructions

Screenshots are encouraged to share your testing results for this change.

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

Additional Context

I'm not typescript developer, feel free to close or update PR if needed. This changes was done to test url elicitation for rust sdk.

[Copilot]

Pull request overview

This PR implements URL elicitation support (SEP-1036), enabling servers to request user interaction through URLs (e.g., OAuth flows) in addition to the existing form-based elicitation. The implementation includes a new component for displaying URL elicitation requests with security warnings, updates to client capabilities, and comprehensive test coverage.

Key Changes

• Added URL elicitation mode alongside the existing form mode, with distinct handling for each request type
• Implemented security warnings for non-HTTPS protocols and internationalized domain names
• Extended client capabilities to advertise support for both form and URL elicitation modes

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
client/src/components/ElicitationUrlRequest.tsx	New component for URL elicitation with security warnings, multiple action buttons, and clipboard integration
client/src/components/ElicitationTab.tsx	Updated to handle multiple elicitation modes with type guards and render appropriate components
client/src/components/ElicitationFormRequest.tsx	Renamed from ElicitationRequest and updated to work with typed form requests
client/src/components/tests/ElicitationUrlRequest.test.tsx	Comprehensive test suite covering URL validation, warnings, user interactions, and edge cases
client/src/components/tests/ElicitationFormRequest.test.tsx	Updated test imports and types to reflect component rename
client/src/lib/hooks/useConnection.ts	Updated client capabilities to include form and url elicitation support, added ElicitationCompleteNotificationSchema
client/src/lib/hooks/tests/useConnection.test.tsx	Updated test expectations for new elicitation capabilities structure
client/src/App.tsx	Updated to pass all elicitation request parameters including mode, url, and elicitationId

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

While window.open includes "noopener,noreferrer" security flags (good practice), there's no validation to prevent opening potentially dangerous URL schemes like "javascript:", "data:", or "file:". Consider adding scheme validation to only allow http: and https: protocols before opening the URL, even though the warning system alerts users about non-HTTPS URLs.

Suggested change

	if (parsedUrl.protocol !== "http:" && parsedUrl.protocol !== "https:") {
	return;
	}

[olaservo]

Hi @pbezglasny , looks like you resolved this but the handleAcceptAndOpen function still doesn't validate URL schemes before opening. Should we add the suggested filter for only allowing http or https?

[He-Pin]

Thanks for bring this in.

[olaservo]

Thanks for the PR and sorry for the wait in reviewing. I left a few comments. Also since the Everything Server doesn't support URL mode yet (tracked in modelcontextprotocol/servers#3034) I think we'd want to add it there first, before releasing this change, since we usually prefer having parity there to support testing with that server.

[olaservo]

Looks like the warning message text doesn't match between code and tests:

• Code (ElicitationUrlRequest.tsx:73): "This URL contains internationalized (non-ASCII) characters"
• Tests: "This URL contains internationalized characters"

Please update one to match the other.

[olaservo]

Looks like CI is failing due to formatting issues, please run npx prettier --write client/src/components/ElicitationUrlRequest.tsx to resolve.

[olaservo]

Hi @pbezglasny , looks like you resolved this but the handleAcceptAndOpen function still doesn't validate URL schemes before opening. Should we add the suggested filter for only allowing http or https?