Advanced UI

Build views and dashboards

A tool answers a question; the UI shows the proof. The UI builder binds real OData results into widgets and renders them as MCP UI resources inside an AI client, so an answer is something your team can see and act on. You build two things here: a view (one focused surface) and a dashboard (several surfaces on one canvas).

Build a view

Views

A view is a focused review surface bound to a data source. You lay it out on a drag-and-drop, 12-column responsive grid, and there are two ways to place and configure each widget.

Drag and drop

Drag a widget from the palette straight onto the canvas, then drag a field onto it to bind data. Reposition and resize widgets directly on the grid.

Right-side options

Select any widget to open the options panel on the right. Every change you make there (fields, titles, formatting) applies to the selected widget on the canvas.

  1. 1

    Create a view

    Console -> UI builder

    Open the UI builder and start a view. You can begin from a blank canvas and add widgets yourself, or open a starter layout and edit its blocks directly.

    What you'll see

    A blank view canvas in the UI builder.

    This is where the product screen for this step will appear.

  2. 2

    Add a data source

    UI builder -> Data sources

    A widget renders nothing until it has data. Bind an alias to a source so widgets can reference its fields with {{alias.fieldName}}. Two kinds of source are supported:

    • odata_tool: a generated tool with an operation, either filter to list,get to fetch one by key, or count for a total.
    • static: sample rows you supply by hand, useful for layout before a service is connected.

    Binding a source is read-only. It does not run a write of any kind.

    What you'll seeSource bound

    The panel records the binding:

    • Alias orders mapped to an odata_tool source
    • Operation filter, with optional $filter, order, and a max-record cap
    • Fields from the bound entity are now available to widgets
  3. 3

    Place and configure widgets

    UI builder -> Widgets / Options

    Add widgets either way described above: drag them from the palette, or add one and shape it from the right-side options panel. The catalog covers the shapes a review surface needs:

    • table and list for rows of records
    • stat and metric for a single headline number
    • chart for distribution and trend, and card for a record summary
    • text and headings for context, plus button, badge, link, image, and progress
    What you'll seeWidget configured

    For the selected widget, the right-side options control:

    • Which source fields it shows, and the column or value mapping
    • Title, formatting, and display options
    • Size and position on the 12-column grid
  4. 4

    Bind fields and arrange the grid

    Drag a field from the data-source panel onto a widget to bind it, or pick fields in the options panel. A table gains a column per field, a stat takes a value, and a chart maps fields to its axes. Each binding resolves to {{alias.fieldName}} against the source you connected. The layout reflows at the mobile and tablet breakpoints.

    What you'll see

    Widgets bound to fields on the 12-column grid.

    This is where the product screen for this step will appear.

  5. 5

    Save and expose as an MCP UI resource

    Saving the view publishes it as an MCP UI resource. An MCP-compatible AI client can then render it inline, so a tool call returns a table or summary the team can read rather than a wall of text. The view stays governed by the same exposure and confirmation rules as the tools it binds. See the MCP UI page for how these surfaces appear inside a client.

    What you'll seeSaved as resource

    The saved view is now available to clients:

    • Exposed as an MCP UI resource alongside your tools
    • Rendered inline by an AI client when the matching tool runs
    • Backed by the live query you bound

Compose a dashboard

Dashboards

A dashboard composes several widgets and data sources onto one canvas, so a single screen answers a broader question. Dashboards use the same grid, widgets, and binding as views.
  1. 1

    Start from a template or a blank canvas

    Console -> UI builder

    Choose dashboard and start blank, or pick a starter template and edit its blocks. The templates give you a sensible layout to adapt rather than a blank grid.

    What you'll seeTemplate chosen

    Starter dashboard templates include:

    • executive and analytics for headline numbers and trends
    • records and sales for record-heavy operational views
    • operations for status and throughput
  2. 2

    Add several data sources

    UI builder -> Data sources

    A dashboard usually pulls from more than one source. Add an alias per source (each an odata_tool or static source), then bind different widgets to different aliases on the same canvas.

    What you'll seeSources bound

    For example, one dashboard might bind:

    • orders to a table and a trend chart
    • customers to a count metric
    • revenue to a headline stat
  3. 3

    Arrange the canvas

    Place widgets across the 12-column grid using drag-and-drop or the right-side options, exactly as you do in a view. The layout reflows for tablet and mobile so the dashboard stays readable on any screen.

    What you'll see

    A multi-source dashboard arranged on the 12-column grid.

    This is where the product screen for this step will appear.

  4. 4

    Save and expose the dashboard

    Save the dashboard to publish it as an MCP UI resource, the same as a view. A client can render the whole dashboard inline, and it stays governed by the exposure and confirmation rules of every tool it binds.

    What you'll seeSaved as resource

    The dashboard is now available to clients:

    • One MCP UI resource that renders all of its widgets
    • Each widget backed by its own bound source
    • Governed by the same rules as the underlying tools

Related