Widget _meta places csp/prefersBorder on the tool instead of the UI resource #1188

Problem

The widget registry (src/resources/widgets.ts) builds one _meta.ui blob and serves it on every surface — tool descriptor, tool result, resources/list, resources/read. Per the MCP Apps spec (SEP-1865) the fields are surface-specific:

• McpUiToolMeta (tool _meta.ui): only resourceUri + visibility; csp/permissions are typed never — "csp belongs on the UI resource … hosts read it from the resources/read content item (with resources/list entry as fallback) and ignore it here."
• McpUiResourceMeta (resource _meta.ui): csp, permissions, prefersBorder, domain.

Claude's host warns about the current placement at runtime:

Tool 'search-actors-widget' declares _meta.ui.csp/permissions, which is ignored. Declare them on the UI resource instead (resources/read content item, or resources/list entry as fallback).

Net effect today: our declared CSP is ignored by spec-compliant hosts (it sits on the wrong surface), and the resource read echoes tool-only keys. Not a functional outage — hosts ignore the misplaced fields — but the metadata contract is wrong everywhere it appears.

Fix

• Split the single WIDGET_BASE_UI into a tool variant (resourceUri, visibility) and a resource variant (csp, prefersBorder); WidgetConfig carries both (meta for tool/result, resourceMeta for list/read).
• Serve resourceMeta from resource_service.ts on resources/list entries and resources/read content items.
• Add the legacy _meta["ui/resourceUri"] alias on tool meta — the ext-apps SDK's registerAppTool populates it "for compatibility with older hosts".
• Update the widget-meta unit tests to pin the per-surface placement (tool meta must NOT carry csp; resource meta must).

Implementation is prepared and verified (type-check, lint, unit tests, mcpc probe of tools/list + resources/read); it will land as a PR referencing this issue.

🤖 Generated with Claude Code