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?

[rinormaloku]

I wanted to run this but the page doesn't load, and in the console I have this error

installHook.js:1 TypeError: Cannot read properties of undefined (reading 'label')
    at initializeInspectorConfig (index-DsnGbFex.js:42308:44)
    at index-DsnGbFex.js:57215:11
    at Object.hi [as useState] (index-DsnGbFex.js:3615:37)
    at react_production_min.useState (index-DsnGbFex.js:309:23)
    at App (index-DsnGbFex.js:57214:45)
    at Nh (index-DsnGbFex.js:3449:9)
    at Vk (index-DsnGbFex.js:6392:13)
    at Uk (index-DsnGbFex.js:6086:13)
    at Tk (index-DsnGbFex.js:6080:27)
    at Ik (index-DsnGbFex.js:6065:9)
    ```

[mbuotidem]

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

I'm curious why. It would appear most MCP servers currently send a -32042. I think it would be helpful if the inspector automatically converted that into an elicitation request. I've prototyped this in sendMCPRequest: catching UrlElicitationRequiredError and routing each elicitation in e.elicitations to the pending elicitation queue seems to work well.

[cliffhall]

Closing: v1 is deprecated.

Thank you for this contribution, and apologies for the long wait for a response.

v1 will receive security fixes only. We reviewed every open v1 PR for security impact before closing — see the backlog triage in #1819 — and a small number were retained for a final 1.0.5 patch release. This one is a functionality, compatibility, or cleanup change rather than a vulnerability fix, so it is being closed unmerged. This is not a judgment on the quality of the work — it's a consequence of the branch it targets being frozen.

If the underlying problem still exists in v2, we'd genuinely like to know. Please open an issue describing it against v2. Note that we accept external contributions as issues rather than pull requests — maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTORS.md.

Thanks again for taking the time to contribute to the Inspector.