[MCP Apps] Have apps request display mode instead

[martinalong]

Motivation and Context

Addresses issue #41

This adds requestDisplayMode, a way for apps to request display mode changes (go full screen, etc). This is just a request, so is not guaranteed to be honored.

Note that the host can initiate an update of displayMode to inline without it being requested by the app (to ensure that the user always has a standard way to return to the default view)

How Has This Been Tested?

Manually tested

Breaking Changes

No

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

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

commit: 46d38f4

[ochafik]

@claude please review this PR thoroughly, compare it w/ #38, and suggest any renaming that might avoid putting Request in the name of a request type.

[idosal]

Thanks @martinalong, looks good! Please note that there's an open PR for the display mode request (#38). It'd be great for you to sync

[idosal]

How about MUST? App developers will need to rely on this field in cases where they need to adjust the app's view.

[martinalong]

Oh yes good call! also the phrasing is wrong on that first one i realized. Will update to:

* App MUST check if the requested mode is in `availableDisplayModes` from host context.
* It is up to the host whether it honors the request, however regardless of whether it switches to the requested mode, host MUST return the resulting mode in the response.

[martinalong]

compare it w/ #38

I had claude took a look at #38 for comparison. I think after considering it, we should stick to the way it's done in this PR (#152).

B/c this PR does it exactly the way it's done in OpenAI apps sdk (so easier for apps to move over), but with the addition of hostContext.availableDisplayModes (which is necessary in a world where there's multiple hosts with differing support)

Also one issue with the approach #38 is that the only way to know if a display mode is supported is to request a change to that mode. This'll pose a problem b/c then you'll have apps displaying pip or full screen buttons that do nothing.

[martinalong]

@ochafik: suggest any renaming that might avoid putting Request in the name of a request type.

I think we should keep the current naming b/c the naming choice (requestDisplayMode) is to match openai's, and it uses the word "request" to make it clear that the request isn't guaranteed to be honored