fix(spec): use ui/initialize and appInfo in transport handshake example

[kristian-presso]

Fixes the SDK-free handshake example in the "Transport Layer" section of the 2026-01-26 and draft specs, which sends MCP's initialize instead of ui/initialize.

Motivation and Context

The example under "Note that you don't need an SDK to 'talk MCP' with the host" ended with:

const initializeResult = await sendRequest("initialize", {
  capabilities: {},
  clientInfo: {name: "My UI", version: "1.0.0"},
  protocolVersion: "2026-01-26",
});

That is the shape of MCP's client-to-server initialize, not the View-to-Host handshake. The rest of the spec, and McpUiInitializeRequest in src/spec.types.ts, define the handshake as ui/initialize with appInfo, appCapabilities and protocolVersion. Hosts that validate the request reject the example as written (#634 shows the params.appInfo validation error from a production host), so the View never becomes visible.

The draft spec (specification/draft/apps.mdx) had the same block.

Changes, in both files:

• initialize becomes ui/initialize
• clientInfo becomes appInfo; capabilities: {} becomes appCapabilities: {availableDisplayModes: ["inline"]} (the spec says Views MUST declare their display modes)
• a one-line comment says this is the View-to-Host handshake, not MCP's initialize
• the example now sends ui/notifications/initialized afterwards, because the Host MUST NOT send anything to the View until it gets that notification, so code copied from the example would otherwise never receive tool input

The protocolVersion values are unchanged. The MCP initialize example under "Client (Host) Capabilities" is correct, since it is the host-to-server handshake, so this PR leaves it alone.

How Has This Been Tested?

• Type-checked the new request object as McpUiInitializeRequest with tsc --noEmit and parsed it with the generated McpUiInitializeRequestSchema. The new example passes and the old one fails.
• Checked the notification against McpUiInitializedNotification.
• npm test: 438 pass, 2 skip, 0 fail.
• npm run prettier: clean.
• npm exec typedoc -- --treatValidationWarningsAsErrors --emit none: clean.

The .mdx spec files are not in the repo's Prettier glob. Running Prettier on them directly reports pre-existing style issues on main, so I left them alone to keep this diff small.

Breaking Changes

None. This only changes docs.

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

Fixes #634

AI assistance disclosure: prepared with Claude Code, which I use as my coding agent. It found the affected examples, checked the corrected request against spec.types.ts and the generated Zod schema, made the edit and drafted this description. Happy to answer questions on any of it.

🤖 Generated with Claude Code