Add ui/close-resource request for UI to initiate termination

[fredericbarthelet]

Fixes #203

Motivation and Context

Implement bi-directionality on UI termination.
Until now ui/resource-teardown was the only way for Host to initiate UI teardown.
This methods enable UI to initiate its own teardown

Items that might require discussion in this PR:

• naming. Similarly to open-link, message, request-display-mode, the name of the request should be action-first/verb-first. Even if we implement a fire and forget pattern (see next point), I would not include notifications in the name. What do you think of ui/close-resource?
• should this new ui/close-resource message implements a request/response pattern or a fire and forget type of pattern (where UI fires the event like it would fire a notification without ever expecting an answer). I'm leaning towards fire and forget because the host won't be able to send a response if it proceeds accordingly and does indeed terminates the UI
• should we provide a way for the host to refuse terminating the UI or should all ui/close-resource requests be fulfilled? this can be achieved only if we go for a request/response pattern, so I'd not account for this scenario just yet

Types of changes

• 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

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/ext-apps

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/ext-apps@215

@modelcontextprotocol/server-basic-react

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-basic-react@215

@modelcontextprotocol/server-basic-vanillajs

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-basic-vanillajs@215

@modelcontextprotocol/server-budget-allocator

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-budget-allocator@215

@modelcontextprotocol/server-cohort-heatmap

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-cohort-heatmap@215

@modelcontextprotocol/server-customer-segmentation

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-customer-segmentation@215

@modelcontextprotocol/server-map

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-map@215

@modelcontextprotocol/server-pdf

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-pdf@215

@modelcontextprotocol/server-scenario-modeler

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-scenario-modeler@215

@modelcontextprotocol/server-shadertoy

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-shadertoy@215

@modelcontextprotocol/server-sheet-music

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-sheet-music@215

@modelcontextprotocol/server-system-monitor

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-system-monitor@215

@modelcontextprotocol/server-threejs

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-threejs@215

@modelcontextprotocol/server-transcript

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-transcript@215

@modelcontextprotocol/server-video-resource

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-video-resource@215

@modelcontextprotocol/server-wiki-explorer

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/server-wiki-explorer@215

commit: 95bd5ec

[fredericbarthelet]

Hey @liady @idosal
Would love to get your feedback on this first shot at ui/close-resource before going further and adding tests and examples.
Let me know what you think (I raised 3 main points in the PR description worth discussion IMHO) :)

[fredericbarthelet]

Hey @liady @idosal , sorry for the ping. Just rebased my PR on latest changes from the repo.
Did you got a chance to take a look at the implementation?

Thanks !

[liady]

@fredericbarthelet thanks for this! several points:

1. Can you please also add the spec changes to the PR? We don't want the spec to diverge from the SDK implementation, so it's best to group them in a single PR.
2. Naming - ui/close-resource makes sense for the current PR purpose. However the next points would show that it might be ui/request-close:
3. I agree that we shouldn't have a special response if it's ui/close-resource, but why shouldn't we treat it like the UI requesting to be closed? So the host responds with ui/resource-teardown anyway? I saw in the PR that you meant for it to be sent after the UI completed the cleanup process, but what's the reason not to piggyback on the already present ui/resource-teardown>success mechanism?
4. If we're going with the ui/request-close > ui/resource-teardown mechanism, then concpetually the host decides whether to do it or not.

What do you think?