Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

Create Dashboard

mint_dashboard

Check first: list_dashboards, then get_dashboard on anything close. If an existing dashboard answers this question, edit its definition and update_dashboard it instead of minting a second — two dashboards for one question leave no way to tell which is authoritative, and they drift apart. Minting a title that already exists is refused.

Validate, ground, store, and mint a Fixter dashboard link. Call describe_dashboards before first use — it defines the definition JSON this tool accepts.

The dashboard is stored and the link is short and stable: update_dashboard changes what the same link shows, so hand the user both the link and the id. This tool refuses to store definitions that would render broken. It checks the structure (grid rows, panel roles, units, environment scoping), then executes every panel's SQL against your live data — variables resolved, placeholders substituted — and reports empty panels, legend overflows, and dead series. Errors block the link; warnings ship with it and belong in your handover message.

Compose with grounded queries (run_sql) first; this tool verifies, it does not design.

Input Schema

NameRequiredDescriptionDefault
rangeNoOptional range override for the link, <n>m|h|d, e.g. 24h.
refreshNoOptional refresh interval override in ms; 0 disables.
definitionJsonYesThe dashboard definition as a JSON string, schema per describe_dashboards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / refresh / format
      Added value: +"int32"
  2. Added
  3. Removed
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: title collisions are refused, broken definitions are rejected, every panel's SQL is executed against live data, errors block the link while warnings ship with it. It also explains link stability (update_dashboard changes the same link) and why duplicates are harmful. Annotations only declare the generic write/safety profile.

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

Conciseness4/5

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

Dense but nearly every sentence carries actionable content (workflow, refusal semantics, validation behavior, composition). Mild criticism: the actual purpose sentence is buried in the second paragraph behind workflow guidance, so the opening is not maximally front-loaded.

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?

For a complex write tool with no output schema, it covers the mutation's side effects, validation behavior, and even the two artifacts to hand back (link and id). It stops short of describing the exact response/error payload shape, which is the main remaining gap.

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

Parameters3/5

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

Schema description coverage is 100%, so both optional overrides (range, refresh) and definitionJson are already documented in the schema, which points to describe_dashboards for the JSON shape. The description adds little parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

Purpose5/5

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

States a specific chain of actions ("Validate, ground, store, and mint a Fixter dashboard link") and names the object precisely. It distinguishes itself from update_dashboard (edits an existing link), describe_dashboards (defines the JSON), and list_dashboards/get_dashboard (discovery), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not: check list_dashboards then get_dashboard, and prefer update_dashboard over minting a duplicate. Prerequisites are spelled out (call describe_dashboards first, compose with run_sql), and it states the tool verifies rather than designs.

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

All Fixter toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources