ext-apps

Motivation and Context This change adds support for the 'tools' permission from the WebMCP specification, mapping it to the Permission Policy 'tools' feature. How Has This Been Tested? I've tried it locally by adding this code in my files: Then, I used WebMCP - Model Context Tool Inspector extension to verify it was properly registered. Without this PR, registration fails because of the missing on both iframes. Breaking Changes Nope. Types of changes [x] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed (I've assumed schema.json will be part of the documentation) Additional context

Fixes #678 Motivation and Context Provide an app controlled way to advertise in-view links that host MAY allow user to navigate to with minimal user friction (removing confirmation modal on redirection). How Has This Been Tested? In the basic host implementation Breaking Changes None, only added as an optional property Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context Removed the override from root in order to be able to up to in basic-host exemple and use the recent class to implement link URL testing against trusted domains.

Summary The spec defines how a host renders a view once a tool with a ui.resourceUri returns, but it doesn't say what a host should do when that tool call returns an error result (isError: true). Hosts are diverging, and I'd like a recommendation (ideally normative) so implementations stay consistent. ChatGPT unmount the view iframe (it was already mounted when the output was received) Claude doesn't mount the view iframe Goose keep the iframe mounted and proceed with rendering as usual. The value is not accessible from the view. What the spec covers today The ui/notifications/tool-result notification and the rendering flow describe the success path (result.content / structuredContent are forwarded to the view). There's ui/notifications/tool-cancelled for cancellation, but nothing addresses a completed tool call whose result has isError: true, e.g.: Questions When a tool result has , should the host skip rendering the view and fall back to the normal error/text presentation? If the view is still rendered, should the host deliver the error via ui/notifications/tool-result (with preserved), via a distinct signal, or not at all? If the same notification is used, how to access the boolean?