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?

[fredericbarthelet]

Hey @liady, thanks for your comments.

I'll add the spec changes and tests to the PR.
I did not go with piggy-backing on existing ui/resource-teardown implementation, because it felt like the resulting Host/Guest conversation would have been:

• Guest: I want to terminate.
• Host: Sure, I'll terminate you, please proceed with saving and cleaning up.
• Guest: I'm done cleaning up
• Host: OK, shutting you down

while, given it was at the guest initiative, it could have been much simpler:

• Guest: I'm ready to shut down, please terminate.
• Host: OK, shutting you down

For the sake of clarity (and steering away from this conversation analogy 😅), here are the 2 options as sequences.

Option A: ui/close-resource (current PR)

Simpler.
Guest UI is initiating, so it can cleanup before.
UI can freeze while calling this method (should terminate while promise isn't resolved)

sequenceDiagram
    participant Host
    participant Guest

      note right of Guest: App performs cleanup first
      Guest->>Guest: saveState(), cleanup()
      Guest--)Host: ui/close-resource (request)
      note left of Host: Host unmounts immediately
      Host->>Host: iframe.remove()

Loading

Option B: ui/request-close → ui/resource-teardown

Piggy-back on existing implementation of ui/resource-teardown request which avoids app having to implement shutdown procedure both on host initiated and on guest initiated

sequenceDiagram
    participant Host
    participant Guest
    
    Guest--)Host: ui/request-close (notification)
    note left of Host: Host decides whether to close
    alt Host approves close
        Host->>Guest: ui/resource-teardown (request)
        note right of Guest: App performs cleanup
        Guest->>Guest: saveState(), cleanup()
        Guest-->>Host: {} (success response)
        Host->>Host: iframe.remove()
    else Host denies close
        note left of Host: Host ignores or defers
    end

Loading

I can go with option B if you deem it more appropriate here. Let me know :)

[fredericbarthelet]

Hey @liady, happy to go with option B if you prefer it this way. Just let me know and I'll update my PR, documentation and add tests accordingly :) Thanks !

[idosal]

Thanks @fredericbarthelet, awesome contribution!

View removal may be deferred by the Host or outright blocked, and the view needs to know that it's still running business-as-usual. In that time, data might have mutated (e.g., the user continued to interact with it). That data would now need to be handled gracefully. This leads me down the path of resource-teardown, which would handle this case and spare the app from having to develop two separate mechanisms

[liady]

@fredericbarthelet yes, I think for now option B might be preferrable, since it builds on top of the current mechanism, and still leaves the lifecycle control in the hands of the host, preventing possibly surprising edge cases. The view still gains the ability to initiate this process. So I'd recommend implementing B for now.

Do you see a specific use-case in favor of option A - where the view "has" to first initiate its own termination and only then notify the host?