Skip to main content
Glama

Create dashboard

create_dashboard

Create a hosted dashboard; returns its public URL. Dashboard spec: {"title": str, "description"?: str, "range"?: "1m"|"3m"|"6m"|"ytd"|"1y"|"2y"|"5y"|"10y"|"max", "theme"?: "auto"|"light"|"dark" (default mode; auto follows the viewer's system and viewers can switch), "layout"?: "auto"|"overview"|"detail" (only the default for panels without "display": overview makes them tiles, detail makes them charts, auto makes them tiles above 8 panels), "visibility"?: "public"|"private" (default public: anyone with the link; private: only members of this account signed in to tlly.dev, so embeds and shared links stop working for others), "panels": [{"title"?: str, "series": "name" | ["a","b"], "type"?: "line"|"area"|"bar"|"stat"|"gauge"|"bargauge"|"pie"|"heatmap"|"table", "unit"?: str, "note"?: str, "stale_after_days"?: num, "thresholds"?: {"red_above"?, "yellow_above"?, "yellow_below"?, "red_below"?}, "range"?: (as above, overrides the dashboard's), "section"?: str (starts a new titled section at this panel), "views"?: bool (show the Level / Y/Y % / Index buttons; default: shown unless the unit is already a rate like %, y/y or pp), "display"?: "tile"|"chart" (tile: a compact number with a sparkline, click for the full chart; chart: a card with the full chart; mix them freely, e.g. tiles for the many supporting numbers and charts for the few that need their history), "headline"?: bool (show as a big number at the top of the dashboard, under a status strip; use for the 3-6 most important), "width"?: "half"|"full", "scale"?: "linear"|"log", "id"?: str (stable panel id, e.g. pn_abc123XYZ012; keep existing ids when editing so alerts stay attached), "right_axis"?: [series names] (line, area and bar charts: draw these series against a second y axis on the right, for series of different sizes or units; at least one stays on the left), "right_unit"?: str (unit of the right axis; "unit" is the left's), "left_label"?/"right_label"?: str (≤40 chars, a title written vertically along the left / right y axis, e.g. "Policy rate"; right_label needs right_axis), "view"?: "level"|"yoy"|"index" (initial view; viewers can switch), "source"?: str (shown as "Source: …"; defaults to the job's host), "labels"?: [display name per series], "status_series"?: name (a red/yellow/green text series that sets the panel colour), "compare"?: "prev"|"3m"|"1y" (what the change is measured against), "period"?: "D"|"M"|"Q" (show dates as 2026-06 or 2026Q2), "value_names"?: {"green": "Hold", …} (display names for text values)}], "badge"?: "worst" (default: the header badge shows the worst panel) | "off" | panel index (0-based; the badge follows that panel), "shade"?: [{"from": date, "to": date, "label"?: str}] (up to 20 shaded periods on every chart)}. "type": "table" shows one row per series (up to 20): label, latest value, date and a status dot; its "status_series" is a list with one entry per row ("" for none). "area" is a line chart filled underneath; "gauge" is a dial of the latest value with the threshold zones, and "bargauge" a horizontal bar per series (up to 20, coloured by thresholds), both scaled by "min"?/"max"?: num (default 0 to a bit above the largest value or threshold); "pie" is a donut of the series' latest values (shares of a whole, up to 20); "heatmap" is a calendar of the first series' daily values (good for activity per day). Status colour is computed from the latest value of the panel's first series; a series of red/yellow/green labels (e.g. a derived status) colours itself. Notes may use {latest}, {date}, {period} and {change}, filled in from the panel's latest value. Annotations on a panel's series appear as markers. Viewers can pick a time range (1M to Max, year to date, or a custom from-to period), zoom, switch views and download CSV; ?embed=1 hides the page chrome and &panel=N shows one panel. Text limits: title ≤120, description ≤500, panel title ≤120, unit ≤20, note ≤280, section and source ≤80 characters, single line, plain text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "spec": "<spec>"
    },
    "name": "create_dashboard"
  }
}

Input Schema

NameRequiredDescriptionDefault
specYesdashboard spec

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds useful behavioral context beyond annotations: it states that a public URL is returned, explains default public visibility and the consequences of private visibility, and describes embed/viewer behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the spec documentation is a dense wall of prose with no bullets or structured formatting. Much of the length is justified by the nested dashboard spec, but the presentation could be more scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the complex dashboard spec thoroughly and notes that a public URL is returned, which is important because no output schema exists. It does not discuss authentication, permissions, or error behavior, but for a create tool with a detailed spec this is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only exposes a generic "spec" object with the description "dashboard spec." The description compensates by documenting the full dashboard spec, including field meanings, defaults, enums, text limits, and panel-type-specific behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: "Create a hosted dashboard; returns its public URL." This clearly distinguishes the action and return value, though it does not explicitly contrast with siblings such as update_dashboard or publish_dashboard_version.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit when-to-use guidance or alternatives. It does not say when to call create_dashboard versus update_dashboard, publish_dashboard_version, or list_dashboards.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.