Dashboards

What a Dashboard is

A dashboard is a curated set of MCP Apps that admins assign to people or teams. After sign-in, it appears under Dashboard in each member’s desktop sidebar. Each tile is an MCP App from one of the organization’s Connectors. OpenWork renders the tile as real, interactive UI; what a member does inside it is not sent to the model. When the feature is enabled for the organization, Dashboards appear in the OpenWork Cloud admin sidebar under Manage → Dashboards.

Connect the MCP server

In OpenWork Cloud, open Connectors, click Add connector, paste the Server URL (for example, https://mcp.example.com/mcp), and choose Authentication and Account mode: Individual accounts or Org account. Use Test tools to confirm the server responds. Only connectors that expose at least one MCP App can be added to a dashboard.

Create the dashboard

Open Dashboards, click New dashboard, enter a Name such as Support overview, then click Create dashboard.

Add apps

Click Add app, pick an MCP, choose one of its Apps, and click Add. MCPs without Apps are hidden. If the app’s tool requires input, fill Launch input (JSON). Reorder or remove apps from the list.

Decide how each app runs

Apps run on request by default: the member clicks Run. Turn on Run automatically to run an app on dashboard load and refresh. This also applies to tools that modify data, so enable it only for apps you trust.

Share it

In Access, turn on Everyone in the organization, or leave it off and add specific people and teams. Members see the dashboard the next time they open OpenWork.

What members see

The desktop sidebar shows Dashboard, with one section per assigned dashboard labeled Managed by your organization. Tiles have one of these badges:

Organization auto-run
Run on request
Run once to enable

A tool that is not read-only runs only when the member clicks Run, unless an admin enabled auto-run. MCP Apps are a standard extension of MCP (io.modelcontextprotocol/ui). An app is an ordinary MCP server with a tool that points to a UI resource and that resource served as HTML. OpenWork supports the subset below, not every optional feature of the specification. Apps must check the host’s advertised capabilities. The ext-apps repository provides the SDK and examples.

Supported host protocol

The shared chat and dashboard renderer uses the stable 2026-01-26 protocol with ext-apps 1.7.5:

After initialization, the host sends complete ui/notifications/tool-input arguments before ui/notifications/tool-result. Result delivery retains content, structuredContent, _meta, and the optional isError flag, including explicit false.
Writable Apps advertise serverTools and openLinks. Tool calls retain the originating endpoint, workspace, session, engine (when supplied), and live launch lease through approval and dispatch. Link requests require an active writable view, use the host’s HTTP(S)-only opener, and report failures.
Only inline display is available. Valid ui/request-display-mode requests return the current inline mode, including requests for fullscreen or picture-in-picture; they do not change the layout.
Size notifications adjust the inline height within host limits. Unmount retains the existing bounded ui/resource-teardown handshake and bridge close.
Message/context writes, View-provided tools, and resource proxy requests are not supported by this renderer. Unsupported requests receive protocol errors, not successful empty responses. There is no full progress or cancellation forwarding.

Host surface	Tools and links	Ownership
Active conversation, including a split pane	Advertised for writable views with a live lease	The message list supplies its own client, workspace and session, not the currently selected root workspace.
Live dashboard tile	Advertised while its launch remains active	The exact endpoint and workspace that resolved the tile own its lease; there is no conversation session.
Archived conversation	Neither advertised nor allowed	The original conversation supplies a read-only origin.
Cached dashboard preview	Neither advertised nor allowed until a fresh launch succeeds	Cached data never persists a live lease; Run obtains a new one.
Generated result preview	Neither advertised nor allowed	Explicit read-only origin without a conversation session.

Closing or replacing a view disables its pending actions and releases its owned lease. Dashboard endpoint removal also retires that endpoint’s lease. A restored cached view cannot reuse the previous lease, and the server revalidates launch ownership before dispatching tools. Chat views mount from completed, preserved results; dashboard tiles render successful or saved results. A cancelled in-flight launch therefore has no mounted recipient for ui/notifications/tool-cancelled. Cancelling another operation or unmounting an already completed result does not invent a cancellation notification. Early mounting and streaming launch input are not implemented. Dashboard launch failures retain the existing error or saved-result presentation rather than mounting an actionable failed launch.

Provider data and gateway additions

Provider structuredContent is left unchanged, including fields named serverTools or schemaGuidance. OpenWork gateway additions use reserved _meta keys: openwork/mcpApp for the launch binding, openwork/serverTools for gateway tool names, and openwork/schemaGuidance for advisory schema warnings. Apps should read gateway tool names from result._meta["openwork/serverTools"], not from provider structuredContent.serverTools. Schema guidance is also appended as a separate text content block under openwork/schemaGuidance so the model can use it without seeing private result _meta. Warnings do not invalidate a provider success or justify repeating a successful call. Gateway-generated error payloads may still include schemaGuidance; those payloads are not provider structured data.

Requirements OpenWork checks

The tool’s _meta.ui.resourceUri is a string starting with ui://.
If _meta.ui.visibility is set, it includes "app".
resources/read for that URI returns exactly one content item with mimeType text/html;profile=mcp-app, at most 768 KiB.
Optional _meta.ui.csp on the resource supports connectDomains, resourceDomains, frameDomains, and baseUriDomains: HTTPS origins only, up to 16 each. permissions and domain are not supported; OpenWork rejects a resource containing either.
The server is reachable over HTTP(S) as a remote Streamable HTTP MCP server. Local stdio servers cannot be dashboard apps.
Mark read-only tools with annotations: { readOnlyHint: true }. Tools without it, or with destructiveHint: true, are treated as modifying data and run only on request unless an admin enables auto-run.
The dashboard picker uses title, or annotations.title, as the tile name. It shows a Launch input field when inputSchema.required is non-empty.

Install @modelcontextprotocol/sdk, @modelcontextprotocol/ext-apps, and express, then create these two files.

Create the MCP server

server.ts

import express from "express";
import { readFile } from "node:fs/promises";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import {
  registerAppResource,
  registerAppTool,
  RESOURCE_MIME_TYPE,
} from "@modelcontextprotocol/ext-apps/server";

const server = new McpServer({ name: "team-budget", version: "1.0.0" });
const html = await readFile(new URL("./view.html", import.meta.url), "utf8");

registerAppResource(
  server,
  "budget-view",
  "ui://team-budget/view.html",
  { mimeType: RESOURCE_MIME_TYPE },
  async () => ({
    contents: [{
      uri: "ui://team-budget/view.html",
      mimeType: RESOURCE_MIME_TYPE,
      text: html,
    }],
  }),
);

registerAppTool(
  server,
  "get_budget",
  {
    title: "Team budget",
    description: "Current budget allocation by team",
    inputSchema: {},
    annotations: { readOnlyHint: true },
    _meta: { ui: { resourceUri: "ui://team-budget/view.html" } },
  },
  async () => {
    const data = { teams: [
      { name: "Engineering", percent: 42 },
      { name: "Sales", percent: 33 },
      { name: "Operations", percent: 25 },
    ] };
    return {
      content: [{ type: "text", text: JSON.stringify(data) }],
      structuredContent: data,
    };
  },
);

const app = express();
app.use(express.json());
const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
await server.connect(transport);
app.all("/mcp", (req, res) => transport.handleRequest(req, res, req.body));
app.listen(3000);

Create the view

Bundle this file with Vite so it resolves the package import, or serve the import through an ESM CDN.

view.html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Team budget</title>
    <style>
      body { font: 14px system-ui; margin: 0; padding: 16px; color: #18181b; }
      h2 { font-size: 16px; margin: 0 0 16px; }
      .team { display: grid; grid-template-columns: 100px 1fr 40px; gap: 8px; margin: 10px 0; }
      .track { background: #e4e4e7; border-radius: 4px; overflow: hidden; }
      .bar { background: #2563eb; height: 100%; }
      .value { text-align: right; }
    </style>
  </head>
  <body>
    <h2>Team budget</h2>
    <div id="teams">Loading…</div>
    <script type="module">
      import { App } from "@modelcontextprotocol/ext-apps";

      const root = document.querySelector("#teams");
      const render = (data) => {
        root.replaceChildren(...data.teams.map(({ name, percent }) => {
          const row = document.createElement("div");
          row.className = "team";
          row.innerHTML = `<span>${name}</span><span class="track"><span class="bar" style="display:block;width:${percent}%"></span></span><span class="value">${percent}%</span>`;
          return row;
        }));
      };

      const app = new App({ name: "Team budget", version: "1.0.0" });
      app.addEventListener("toolresult", (params) => render(params.structuredContent));
      await app.connect();
    </script>
  </body>
</html>

Add it to OpenWork

Run the server on a public HTTPS URL, or use a tunnel for testing, then follow the admin steps above. You can test it in chat first: ask the agent to call get_budget, and the tile renders inline.

Tips

Keep the resource self-contained. If it loads remote assets, declare their origins in _meta.ui.csp.
Return shared result data in structuredContent and readable fallback text in content. Treat both as model-visible; put view-only data in result _meta.
One tool can drive one view. Ship several tools for several widgets.

Share with your team

Run in the cloud

MCP Gateway

What a Dashboard is

What members see

Build an MCP App widget

Supported host protocol

Provider data and gateway additions

Requirements OpenWork checks

Example: a Team budget widget

Tips

​What a Dashboard is

​Create and share a dashboard (admin)

​What members see

​Build an MCP App widget

​Supported host protocol

​Provider data and gateway additions

​Requirements OpenWork checks

​Example: a Team budget widget

​Tips

What a Dashboard is

Create and share a dashboard (admin)

What members see

Build an MCP App widget

Supported host protocol

Provider data and gateway additions

Requirements OpenWork checks

Example: a Team budget widget

Tips