Build a ChatGPT App UI from MCP tool results

Real workflow example

An MCP tool searches a private project database and returns matching tasks. The first ChatGPT App component renders the raw results as a pretty list, but users still have to read every item and decide what matters.

The better UI is built around the next action. It groups tasks by status, highlights blocked work, shows source links, lets the user select rows, and sends a structured follow-up action back through a tool. The component is useful because it turns tool output into a review surface.

Implementation approach

Design the MCP response before the component. The tool should return structured data the UI can render directly: IDs, titles, statuses, owners, dates, source URLs, warnings, and allowed actions. Avoid making the component parse prose.

The component should own presentation state such as selected rows, filters, expanded details, and temporary draft text. Durable state belongs on the server and should change only through authorized tool calls or backend APIs.

Build empty, loading, error, partial, and ready states. ChatGPT App components often receive imperfect tool results, so missing fields should degrade gracefully.

Code or config snippet

type ToolTaskResult = {
  id: string;
  title: string;
  status: "todo" | "in_progress" | "blocked" | "done";
  owner?: string;
  sourceUrl: string;
  allowedActions: Array<"open" | "summarize" | "create_followup">;
};

type ToolResponse = {
  query: string;
  results: ToolTaskResult[];
  warnings: string[];
};

Mistakes to avoid

• Do not return one prose paragraph when the UI needs rows, statuses, and actions.
• Do not put secret or privileged data into component state.
• Do not assume every tool response has complete fields.
• Do not implement business authority only in the UI.
• Do not build a decorative panel that does not improve inspection or action.

Ready checklist

• MCP tool response is structured and typed.
• Component renders loading, empty, error, partial, and ready states.
• UI state is limited to presentation and drafts.
• Durable actions go through authorized tools or server endpoints.
• Sensitive fields are minimized or omitted.
• Missing data renders without breaking layout.

Practical tip

Write the component using saved fixture responses before connecting the live MCP tool. You will catch most state and layout problems faster with static examples for empty, partial, crowded, and error results.