dashboardbase
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@dashboardbaseValidate my dashboard setup file and report errors or warnings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This is the official MCP server for dashboardbase. Add it to your AI tool and it can check a widget endpoint's response — or a whole dashboard setup file — against the contract dashboardbase actually enforces, before you ever open the app.
The dashboardbase skill teaches your agent the JSON contract. This MCP lets it check its own work. Use both: the skill gets the shape right, the MCP proves it.
What this MCP does
It gives your agent two tools:
Tool | What it checks |
| A dashboardbase setup file — the JSON that provisions a whole dashboard's widgets and datasources. Reports errors and warnings with the field, line and column. |
| The JSON body a widget endpoint returns, against the widget contract. Reports the path and message for each problem. |
Both call the public dashboardbase validation API. No account, no API key, nothing to configure.
Related MCP server: kube-lint-mcp
Before / after
Without it — your agent writes an endpoint, you deploy it, you wire it into dashboardbase, the widget shows an error, you go read the docs, you fix it, you deploy again.
With it — your agent writes the endpoint, validates the response, fixes the two things that were wrong, and hands you something that renders the first time.
Invalid setup file — 2 errors, 1 warning
mappings[0].type 14:9 Unknown widget type "guage"
mappings[1].path 22:5 Path must start with "/"
warning mappings[2] No refreshInterval setInstall
Claude Code
claude mcp add dashboardbase -- npx -y @dashboardbase/mcpOne click
Claude Desktop
Download dashboardbase-mcp.mcpb from the latest release and drag it into Claude Desktop's extensions settings. The bundle is self-contained — you don't even need Node.
Cursor, Windsurf, and most other clients
These use the mcpServers shape. Add it to ~/.cursor/mcp.json (Cursor), ~/.codeium/windsurf/mcp_config.json (Windsurf), or your client's equivalent:
{
"mcpServers": {
"dashboardbase": {
"command": "npx",
"args": ["-y", "@dashboardbase/mcp"]
}
}
}VS Code
VS Code is the exception — it uses servers rather than mcpServers, and requires an explicit type. In .vscode/mcp.json (workspace) or your user profile:
{
"servers": {
"dashboardbase": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@dashboardbase/mcp"]
}
}
}Codex CLI
Codex uses TOML. Easiest is the CLI:
codex mcp add dashboardbase -- npx -y @dashboardbase/mcpOr by hand in ~/.codex/config.toml:
[mcp_servers.dashboardbase]
command = "npx"
args = ["-y", "@dashboardbase/mcp"]Requires Node.js 20 or newer — that's the only prerequisite, and only for the npx routes. Nothing else to configure: the validation API is public, so there's no account, key or environment variable to set.
Staying up to date
Two different things arrive by two different routes, which is worth knowing:
Better error messages arrive on their own. The server holds no schemas — it calls the live API — so as validation messages improve, you see them immediately. Nothing to update.
New tools need a package update. If a release adds a tool, you get it once the package updates and your client restarts the server. A running server's tool list is fixed for the session.
How you installed | How you update |
| Automatic — restart your client and the next server start picks up the newest version. |
Claude Desktop | Pinned at install. Download the new bundle from releases and drag it in again. |
Docker |
|
Check what you're running:
npx -y @dashboardbase/mcp --versionIf that reports an older version than the latest release, npm is serving cached registry metadata — a just-published version can take a few minutes to show up. Force it:
npx -y @dashboardbase/mcp@latest --versionReleases follow semver: new tools are a minor bump and never break existing calls, so updating is safe by default.
Using it
First, check it's connected
claude mcp listYou should see dashboardbase listed as connected. Inside a Claude Code session, /mcp shows the server and its two tools. In other clients, look for dashboardbase in the MCP or tools panel.
If it isn't there, the server never started — check that node --version is 20 or newer, and that your config file has valid JSON.
Then just ask
You don't call these tools yourself. Describe what you want and the agent decides to call them, the same way it decides to read a file. There's no special syntax and nothing to remember.
Validating something you already have:
"Validate my dashboardbase setup file"
"Is
.dashboardbase/revenue.jsonvalid?""Check this against the dashboardbase contract" — then paste the JSON
Validating as part of building:
"Build a KPI endpoint for MRR, then validate the response it returns"
"Add a gauge widget to my setup file and make sure it still validates"
Debugging something broken:
"My gauge widget shows an error in dashboardbase — check what my endpoint returns against the contract"
"Why is dashboardbase rejecting my setup file?"
What it looks like
You: My revenue widget isn't rendering. Check
.dashboardbase/revenue.json.Agent: calls
validate_setup_fileInvalid setup file — 2 errors mappings[0].type 14:9 Unknown widget type "guage" mappings[1].path 22:5 Path must start with "/"Agent: Two problems —
guageis a typo forgauge, and the second mapping's path is missing its leading slash. Fixing both now.edits the file, calls
validate_setup_fileagainValid setup file — no errors.
That loop — validate, fix, re-validate — is the whole point. The agent closes it without you opening dashboardbase.
Or invoke it directly
In Claude Code, the server adds a slash command — type / and it's in the menu:
/mcp__dashboardbase__validate .dashboardbase/revenue.jsonLeave the path off and it validates whatever you're working on, or whatever you paste next. This is the deterministic route: it doesn't depend on the agent deciding the tool is relevant.
The middle segment comes from the name you installed under. If you ran
claude mcp add dashboardbase …it's/mcp__dashboardbase__validate; install it as something else and that segment changes to match.
In clients that don't support MCP prompts, just name the tool in plain language:
"Use validate_setup_file on .dashboardbase/revenue.json"
"Use validate_widget_response to check this"
Agents sometimes need the nudge the first time; after that they usually pick it up on their own.
The two tools
Tool | Arguments | Notes |
|
| Give one or the other. |
|
| Inferred from the response when |
Two things worth knowing:
pathonly exists over stdio. A hosted HTTP deployment has no access to your disk, so the parameter isn't offered there — passcontent/responseinstead.validate_widget_responsewants the full response body — thetitle/actions/data/alertenvelope your endpoint actually returns, not just the innerdatapayload.
Configuration
Everything is optional.
Variable | Default | Purpose |
|
| Point at a different environment. |
| unset | Sent as |
|
| Request timeout in milliseconds. |
Running it as an HTTP server
For containers or a shared internal deployment:
npx @dashboardbase/mcp --http --port 3000
# or
docker build -t dashboardbase-mcp . && docker run -p 3000:3000 dashboardbase-mcpServes Streamable HTTP at /mcp and a health check at /health. It's fully stateless, so it scales horizontally with no session affinity. Browser origins are refused unless you allowlist them with --allowed-origin https://example.com. The file-reading path parameter is not exposed in this mode.
What's in the repo
mcp/
├── src/
│ ├── index.ts # CLI entry — stdio by default, --http optional
│ ├── server.ts # Registers the two tools
│ ├── api.ts # Client for the dashboardbase Tools API
│ ├── format.ts # Renders results as readable text
│ ├── http.ts # Stateless Streamable HTTP handler
│ └── tools/ # One file per tool
├── test/ # Unit tests, no network required
├── tools.json # OpenAPI spec for the validation API
├── server.json # MCP Registry manifest
├── manifest.json # Claude Desktop bundle manifest
└── DockerfileHow validation works
The server doesn't carry a copy of the schemas — it calls the live dashboardbase validation API. So it can't drift from what the platform accepts, and error messages get better as the API does, with nothing to upgrade on your side.
That applies to the validation rules and messages, not to the server itself — a release that adds a tool still needs a package update. See Staying up to date.
Related
dashboardbase — the product. Build, host, and share dashboards from your APIs.
dashboardbase skill — teaches your agent the JSON contract so it writes correct endpoints in the first place. Pairs directly with this MCP.
Documentation — widget reference, JSON contract, webhook setup.
Contributing
Found a gap or a confusing error? Open an issue. Note that the validation rules themselves live in the dashboardbase backend — if a message is unclear that's still worth reporting here, and we'll fix it upstream.
License
MIT — see LICENSE. Fork it, adapt it, ship it.
The MIT license covers the code in this repo. "dashboardbase" is a trademark of dashboardbase — see dashboardbase.com. You're free to use and adapt the server; please don't use the name or branding in a way that implies official affiliation.
Available Tools
2 toolsvalidate_setup_fileValidate Dashboardbase setup fileARead-only
Validate a Dashboardbase setup file (the declarative JSON that provisions a dashboard, usually stored at .dashboardbase/.json). Returns whether the file is valid plus any errors and warnings, with the JSON path, field and line/column of each problem. Use this after writing or editing a setup file, before telling the user it is ready to import.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the file to validate, absolute or relative to the working directory. | |
| content | No | The full text of the setup file. Provide this or `path`. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the setup file passes validation. |
| errors | Yes | Problems that make the file invalid. |
| warnings | Yes | Non-fatal advice about the file. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint annotation by specifying exactly what the tool returns: 'whether the file is valid plus any errors and warnings, with the JSON path, field and line/column of each problem.' This gives the agent expectations about output details, though it doesn't describe edge-case behavior (e.g., both or neither parameter provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and every clause serves a purpose: what the file is, typical location, return value, and when to use it. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema that likely details the return structure, the description covers the essential context: what the tool does, what file it targets, what it returns, and when to use it. The 2-parameter schema with full descriptions and annotations complete the picture, making the description sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (path and content), including the note to provide one or the other, achieving 100% coverage. The description adds only a minor contextual detail (the usual storage location .dashboardbase/<name>.json), which does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a Dashboardbase setup file, specifying it's a declarative JSON that provisions a dashboard and typically stored at a known path. It also distinguishes from the sibling tool by focusing on setup files, and the return format (validity plus errors/warnings with paths, fields, and line/columns) is explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this after writing or editing a setup file, before telling the user it is ready to import.' This clearly communicates when to use the tool, though it does not mention when not to use it or reference the alternative sibling tool, so it lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_widget_responseValidate Dashboardbase widget responseARead-only
Validate the JSON body a Dashboardbase widget endpoint returns, against the widget contract. Pass the complete response body — the envelope with title, actions, data and alert — exactly as the endpoint returns it, not just the inner data payload. Returns whether the response is valid, the widget type it was checked against, and the path and message of each problem. Use this after building or changing an endpoint that Dashboardbase will poll.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to the file to validate, absolute or relative to the working directory. | |
| response | No | The full response body from the widget endpoint, including the title/actions/data/alert envelope. Accepts a JSON object or a JSON string. Provide this or `path`. | |
| widgetType | No | Optional widget type to check against, for example "kpi", "line" or "table". Inferred from the response when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | True when the response passes validation. |
| errors | Yes | Problems that make the response invalid. |
| widgetType | No | The widget type the response was validated against. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what the tool returns (validity, widget type, per-problem paths and messages) and details the required input shape (full envelope, not just data). This goes beyond the readOnlyHint and openWorldHint annotations, adding useful behavioral context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and every sentence contributes: what it does, the critical input requirement, the return value, and the recommended usage context. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is well-covered by the output schema (which explains return values), annotations, and a 100% schema-described parameter set. The description fills the remaining gaps: when to use it and the critical envelope requirement. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a valuable nuance by warning 'not just the inner `data` payload,' which is not explicitly captured in the schema's response property description. It also reinforces the path/response alternative already noted in the schema, but adds no additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Validate the JSON body a Dashboardbase widget endpoint returns, against the widget contract.' This clearly distinguishes it from the sibling validate_setup_file, which validates a setup file instead of a widget response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use this after building or changing an endpoint that Dashboardbase will poll.' It also instructs to pass the complete envelope, not just the inner data. However, it does not explicitly state when not to use the tool or name the sibling as an alternative, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
validate_setup_file - First observed
validate_widget_response
TDQS
Both tools validate different artifacts, but their similar verb prefix could cause slight confusion. However, descriptions clearly separate setup files from widget responses, so an agent can easily distinguish based on the 'what' being validated.
Consistent 'validate_<object>' pattern with clear object nouns; no mixing of styles or verb forms.
Only two tools feels minimal for a server, but for a focused validation utility it's acceptable; still, it is below the typical 3-15 range and may feel thin.
The two validations cover the two key Dashboardbase artifacts (setup files and widget responses), but there might be other validation scenarios (e.g., dashboard runtime configs) not addressed, leaving minor gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Monitor MCP servers, API contracts and AI outputs for schema drift. Alerts on breaking changes.
Dashboards as data. Author, validate, render, and share dvt dashboards from any MCP client.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server that checks the Baseline status using Web Platform APIs.37MIT
- AlicenseNot gradedqualityAmaintenanceMCP server to lint and validate Kubernetes-related manifests(Helm, FluxCD, ArgoCD, Kustomize, etc.)MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server for validating JSON against schemas, checking email deliverability, verifying URLs, assessing data quality, and validating API responses using RFC-compliant checks and heuristic analysis.12MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for validating JSON against JSON Schema and repairing malformed/invalid JSON.61-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dashboardbase/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server