Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Explore UI views that are not tied to specific tool calls

Open
#672 4 comments 3 reactions 1 assignee View on GitHub

@liady is already working on this.

Since Jul 8, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement

Hypothesis: the core "attach a widget to a tool call" architecture is the part that doesn't hold up.

Who builds the UI - third-party, first-party, or model-generated - matters less than two things: the model choosing which UI to show and when, and a feedback loop that gives it signal on whether that choice was good.
Today an MCP App view is meant as a template for a tool response. But we increasingly see use cases where a company wants to define UI for data the model produces, regardless of where that data originated. The data/visualization split — companies shipping two tool sets, one for data and one for rendering - keeps coming up, and we should probably recommend it as best practice.

A model where MCP Apps expose views with an input schema, not bound to a specific tool call, could work much better if the feedback loop exists. We tried to approximate this by recommending dedicated render* tools, but conventions don't get followed.

Dominant language
TypeScript
Stars
2.9k
Forks
387
Avg merge
2h 54m
Merged PRs (30d)
7

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/ext-apps

All issues in modelcontextprotocol/ext-apps

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.