Click 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., "@daxops-mcp Build a sales dashboard from my uploaded CSV"
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.
Build Power BI dashboards from your data, straight from Claude Code (or any MCP client).
daxops-mcp is a small, self-contained MCP server that lets a DaxOps account
holder drive their DaxOps cloud from an AI agent: upload your own data and generate Power BI .pbix
dashboards, describe what you want in plain English with the AI prompter, browse the built-in Solution
starters, and manage saved dashboards - all authenticated with your DaxOps license key.
Requirements: Node 18+.
You do not need to clone anything. The published package runs straight from npm.
Run on demand with npx (recommended):
npx -y daxops-mcpOr install it globally:
npm i -g daxops-mcp
daxops-mcpEither way the server reads your license key from the DAXOPS_LICENSE_KEY environment variable and
refuses to start without it (see below). You will normally never run it by hand - Claude Code launches it
for you from the config snippet.
Copy it from your DaxOps account page: https://daxops.com/account. It is the same key the DaxOps desktop app uses. Keep it secret.
Related MCP server: Power BI Report MCP Server
The simplest path - register the published package (Claude Code runs it via npx):
claude mcp add daxops --env DAXOPS_LICENSE_KEY=<your key> -- npx -y daxops-mcp.mcp.json config{
"mcpServers": {
"daxops": {
"command": "npx",
"args": ["-y", "daxops-mcp"],
"env": { "DAXOPS_LICENSE_KEY": "<your key>" }
}
}
}If you are working from a clone of this repo instead of the published package, build it once
(npm install && npm run build) and point the config at the built entry point:
{
"mcpServers": {
"daxops": {
"command": "node",
"args": ["/absolute/path/to/daxops/mcp/dist/index.js"],
"env": { "DAXOPS_LICENSE_KEY": "<your key>" }
}
}
}Variable | Required | Default | Meaning |
| yes | - | Your DaxOps license key (from https://daxops.com/account). The server refuses to start without it. |
| no |
| The DaxOps site origin (override only for a staging instance). |
Tool | What it does |
| List the built-in Solution starters (id, title, industry, description, KPIs). |
| List the brand colour themes you can pass to a build. |
| Upload local |
| Show the detected model (tables, columns, relationships, measures, suggested pages) for a |
| Build a |
| Headline tool. Describe the dashboard in plain English; the AI agent designs and builds it, then downloads the |
| Download a finished build's |
| List your saved dashboard definitions. |
| Save a reusable dashboard definition (name + solution/sourceId + pages/brand). |
| Fetch one saved dashboard's full definition by id. |
| Delete a saved dashboard by id. |
Some tools (data upload, model introspection, saved dashboards) require the +Validation feature on your DaxOps plan; without it the API returns a clear "this is a +Validation feature" message, surfaced as the tool error.
"Use daxops_ai_build to make a multi-page sales report from my uploaded CSVs - an exec overview with KPI cards, a sales trend, and breakdowns by brand and by retailer."
"Upload sales.csv and regions.xlsx, then introspect the model and tell me what pages you'd suggest."
"List the Solution starters, then build the CFO overview with the ocean theme and save it to cfo.pbix."
"List my saved dashboards and rebuild the one called 'Monthly Exec Pack'."
daxops_list_solutions - or daxops_upload_data { paths: ["sales.csv", "regions.xlsx"] } to get a sourceId.
daxops_ai_build { prompt: "an exec sales overview with YoY growth and a region map", sourceId: "..." }
or daxops_build { solution: "finance/cfo-overview", theme: "ocean", title: "CFO Overview" }.
The .pbix is saved to disk (default ./daxops-<title>.pbix, or your outPath).
Async builds return a job id immediately; the build/AI tools poll until the job is done (a couple of
minutes is normal) and then download the .pbix. If a poll times out, the job id is reported so you can
retry with daxops_download.
Your license key is read only from the DAXOPS_LICENSE_KEY environment variable and is sent only as
an Authorization: Bearer header to your DaxOps site over HTTPS. It is never printed in tool output,
errors, or logs (server logs go to stderr; stdout carries only the MCP protocol).
Your data is processed on DaxOps' servers in Auckland, New Zealand, and the uploaded data is
deleted after the build completes. Only the .pbix you download is kept.
This is commercial software. Use of daxops-mcp requires an active DaxOps account and license key, and is
governed by the DaxOps Terms of Service at https://daxops.com. All rights reserved. It is not open-source
and may not be redistributed.
npm install
npm run dev # tsx watch
npm run typecheck # tsc --noEmit
npm run build # tsc -> dist/Describe the dashboard you want in plain English and DaxOps' AI agent builds it, then downloads the .pbix to disk. Build on a Solution starter (solution) or on your uploaded data (sourceId) - provide exactly one. Consumes AI credits on your account. Polls to completion (this can take a few minutes).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | what you want the dashboard to show / do | |
| outPath | No | where to save the .pbix - a directory or a full *.pbix path; defaults to ./daxops-<job>.pbix | |
| solution | No | a Solution starter id from daxops_list_solutions to build on sample data | |
| sourceId | No | a sourceId from daxops_upload_data to build on your data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: it is a write operation (build and download .pbix), consumes AI credits, and polls for a few minutes. Annotations indicate readOnlyHint=false and openWorldHint=true, which align with the description. No contradiction.
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 concise with three sentences. The first sentence immediately states the core purpose, followed by usage requirements and behavioral notes. No redundant information.
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 complexity (4 parameters, no output schema), the description covers all necessary aspects: purpose, required mutual exclusivity, credit consumption, polling duration, and output file. The agent has sufficient information to use the tool correctly.
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 has 100% coverage with descriptions, so baseline is 3. The description adds value by clarifying mutual exclusivity of 'solution' and 'sourceId', and by providing context for 'prompt' (describe in plain English) and 'outPath' (default path). This enhances understanding beyond the schema alone.
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's purpose: building a dashboard via AI description and downloading the .pbix file. It specifies the verb 'build' and the resource 'dashboard', and distinguishes from sibling tools like daxops_build (likely a manual build) and daxops_delete_dashboard.
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 provides clear context: use when you want an AI agent to build a dashboard from plain English. It mentions the need to provide exactly one of 'solution' or 'sourceId', and notes that it consumes AI credits and polls to completion. However, it does not explicitly state when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Power BI .pbix dashboard from an uploaded sourceId or a Solution starter, optionally choosing pages and branding, then download it to disk. Polls to completion (this can take a couple of minutes). Provide exactly one of sourceId or solution. If pages is omitted the engine uses the model's default pages.
| Name | Required | Description | Default |
|---|---|---|---|
| logo | No | an optional base64 logo (a data: URI prefix is fine) | |
| pages | No | ordered page keys (e.g. ["overview","trend","by:Region"]); omit to use the model defaults | |
| theme | No | a theme key from daxops_list_themes | |
| title | No | the report title (also seeds the output filename) | |
| outPath | No | where to save the .pbix - a directory or a full *.pbix path; defaults to ./daxops-<title>.pbix | |
| solution | No | a Solution starter id from daxops_list_solutions | |
| sourceId | No | a sourceId from daxops_upload_data | |
| brandColor | No | a #RRGGBB hex brand colour override |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true). The description adds useful behavioral context: long-running operation ('polls to completion, can take a couple of minutes') and that it downloads to disk. No contradictions with annotations.
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 core purpose, then covers constraints and optional behavior. Every sentence adds essential information without redundancy or fluff.
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 8 parameters and no output schema, the description adequately covers the build process, polling, and download. It explains how to specify source, pages, and defaults. However, it lacks explicit mention of return values (e.g., success/failure, file path) and error handling, which would improve completeness.
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 coverage is 100% with all parameters described. The description adds value beyond the schema by specifying the exclusivity constraint (exactly one of sourceId or solution) and the default behavior for pages. This provides additional semantic guidance not present in the schema alone.
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 verb 'Build' and the resource 'Power BI .pbix dashboard'. It distinguishes from siblings like daxops_ai_build and daxops_list_* by specifying the build process with sourceId or Solution starter. The mention of polling and download adds specificity.
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 constraints: 'Provide exactly one of sourceId or solution' and explains default behavior for pages. However, it does not provide guidance on when to use this tool versus alternatives like daxops_ai_build, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one of your saved dashboard definitions by id. Requires the +Validation feature.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the saved dashboard id from daxops_list_dashboards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is write-only (readOnlyHint=false). The description adds no new behavioral traits beyond the basic delete action, such as irreversibility or confirmation requirements.
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?
Single, front-loaded sentence with no wasted words. Could be improved by adding more context, but remains efficient.
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?
No output schema; description does not explain return behavior or confirm deletion success. Lacks context on whether deletion is permanent or what happens to associated data.
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 coverage is 100%. The description adds minimal value beyond the schema, only restating that the id comes from daxops_list_dashboards.
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?
Clearly states the verb 'delete' and the resource 'saved dashboard definitions by id'. Distinguishes from siblings like daxops_save_dashboard and daxops_open_dashboard.
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?
Mentions a prerequisite ('+Validation feature') but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a finished build's .pbix to disk by its job id (e.g. a build that was still running when an earlier call timed out).
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | the job id from a build / ai_build | |
| outPath | No | where to save the .pbix - a directory or a full *.pbix path; defaults to ./daxops-<job>.pbix |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by specifying that the tool saves a .pbix file to disk. It does not contradict the annotations (readOnlyHint=false is consistent with a local side effect).
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 a single, concise sentence that is front-loaded with the verb and resource. No unnecessary words.
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 simplicity (2 parameters, no output schema), the description covers the essential purpose, parameter usage, and a use case. It could mention error handling but is adequate.
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 coverage is 100% with good descriptions. The description adds marginal context (e.g., job id from build/ai_build, default path for outPath), but does not significantly exceed 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 downloads a finished build's .pbix by job id, with a concrete example. It is distinguishable from sibling tools like daxops_build and daxops_ai_build.
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 provides a clear use case (downloading a build that timed out), indicating when to use the tool. However, it does not explicitly state when not to use or name alternatives beyond the example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the detected data model (tables, columns, relationships, measures, date column, dimensions, and suggested report pages) for an uploaded sourceId or a Solution starter. Provide exactly one of sourceId or solution. Requires the +Validation feature.
| Name | Required | Description | Default |
|---|---|---|---|
| solution | No | a Solution starter id from daxops_list_solutions | |
| sourceId | No | a sourceId from daxops_upload_data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds the requirement of +Validation feature, which is behavioral context beyond annotations. No contradictions.
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?
Two sentences, no wasted words. First sentence clearly states purpose and scope. Second sentence gives critical usage constraint and prerequisite.
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?
No output schema, but description lists the full scope of what is returned (tables, columns, relationships, measures, date column, dimensions, suggested report pages). This is sufficient for an agent to understand the tool's output.
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 has 100% coverage with descriptions linking to sibling tool outputs. Description reinforces mutual exclusivity, adding clarity not present in individual parameter descriptions.
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?
Description uses specific verb 'Show' and clearly lists the resources (tables, columns, relationships, measures, etc.). It distinguishes between two input sources (sourceId and solution), which are tied to sibling tools (daxops_upload_data and daxops_list_solutions).
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?
States to provide exactly one of sourceId or solution, giving clear usage direction. Mentions prerequisite 'Requires the +Validation feature.' Does not explicitly state when not to use or list alternatives, but the mutual exclusivity and prerequisite provide strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your saved dashboard definitions (id, name, solution/source, last updated). Requires the +Validation feature.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds the prerequisite of the +Validation feature, providing useful behavioral context beyond the annotations.
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?
Single sentence, no unnecessary words. Efficient and front-loaded with key information.
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?
Covers purpose and a key requirement. Missing details like pagination or ordering, but for a simple list tool with no output schema, it is fairly complete.
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?
No parameters exist in the input schema, so schema coverage is 100% vacuously. With zero parameters, baseline is 4; description adds no further param info.
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?
Description clearly states the action (list), resource (saved dashboard definitions), and returned fields (id, name, solution/source, last updated). It distinguishes from siblings like save/delete dashboards.
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?
Explicitly mentions the required '+Validation feature', giving context. However, it does not explicitly state when to prefer this over other list tools (e.g., list_solutions) but the resource is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in DaxOps Solution starters (id, title, industry, description, KPIs) you can build from with their bundled sample data. Use a returned id as the "solution" argument to daxops_build, daxops_ai_build or daxops_introspect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, which the description complements by specifying that it lists 'built-in' starters with sample data. The description adds value by explaining the return fields, compensating for the lack of an output schema. No contradictions with annotations.
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 a single, well-structured sentence that efficiently conveys the tool's purpose and usage. No extraneous words.
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 has no parameters, no output schema, and clear annotations, the description provides all necessary context: what it lists, the fields, and how to use the results with sibling tools. It is fully adequate for the tool's complexity.
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 has zero parameters, so the description does not need to explain parameters. Baseline 4 is appropriate as there is no missing information.
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 lists built-in DaxOps Solution starters and specifies the fields returned (id, title, industry, description, KPIs). It also distinguishes from sibling tools by explaining how the returned id is used with daxops_build, daxops_ai_build, or daxops_introspect.
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 explicitly instructs the agent to use the returned id as the 'solution' argument for three sibling tools, providing clear guidance on when to use this tool. While it doesn't state when not to use it, this is sufficient for a list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the brand colour themes (key, name, primary colour) you can pass as "theme" to a build. Requires the +Validation feature on your DaxOps plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds the behavioral constraint that the +Validation feature is required, which is not in annotations, thus providing additional transparency.
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 a single sentence with a supplementary note, front-loaded with the main purpose. Every word is informative with no 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?
For a simple read-only list with no parameters and no output schema, the description is fairly complete, covering what is listed, returned fields, and a prerequisite. Minor missing details like result variability (openWorldHint) are acceptable given low complexity.
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 has zero parameters (100% coverage), and the description compensates by explicitly listing the returned fields (key, name, primary colour), which is beyond the schema and helps the agent understand the output.
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 verb 'List' and the resource 'brand colour themes', specifies returned fields (key, name, primary colour), and notes their use in builds, distinguishing it from sibling tools like daxops_list_dashboards.
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 mentions a prerequisite ('Requires +Validation feature') but provides no explicit guidance on when to use this tool vs. alternatives. Since no alternative list themes tool exists, the context is adequate but not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one saved dashboard's full definition (solution/source + pages + branding) by id so you can review or rebuild it. Requires the +Validation feature.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the saved dashboard id from daxops_list_dashboards |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the behavioral constraint of requiring the +Validation feature and explains that the tool returns the full definition, which aligns with read-only intent. No contradictions.
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?
Two sentences conveying all necessary information with no redundant words. Front-loaded with the core action and result, then the prerequisite. Excellent conciseness.
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?
Despite no output schema, the description explains what the full definition contains (solution/source + pages + branding), which is sufficient for a read operation. Also notes the validation feature requirement, covering key contextual aspects.
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 coverage is 100%, and the schema describes the 'id' parameter as 'the saved dashboard id from daxops_list_dashboards'. The description echoes this without adding new semantic detail, so baseline 3 is appropriate.
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 verb (Fetch) and resource (saved dashboard's full definition) with specifics on what is returned (solution/source + pages + branding). It distinguishes siblings: daxops_list_dashboards lists dashboards, daxops_save_dashboard saves, while this fetches one by id.
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 implies usage after listing dashboards (needs id from list_dashboards) and states a prerequisite ('Requires the +Validation feature'). It provides context for review/rebuild but lacks explicit when-not or alternative guidance beyond what's obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a reusable dashboard definition (name + solution-or-sourceId + chosen pages/branding) so you can reopen and rebuild it later. Provide exactly one of sourceId or solution. Requires the +Validation feature.
| Name | Required | Description | Default |
|---|---|---|---|
| logo | No | an optional base64 logo | |
| name | Yes | a name for the saved dashboard | |
| pages | No | ordered page keys | |
| theme | No | a theme key from daxops_list_themes | |
| title | No | the report title | |
| solution | No | a Solution starter id from daxops_list_solutions | |
| sourceId | No | a sourceId from daxops_upload_data | |
| brandColor | No | a #RRGGBB hex brand colour |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and potential side effects (openWorldHint=true). The description adds the prerequisite of +Validation and the purpose of persistence, but lacks details on overwrite behavior or return state.
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 with no fluff. The first sentence covers purpose, the second provides usage guidance. Every sentence is necessary and front-loaded.
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 number of parameters (8) and full schema coverage, the description explains the core concept and key constraint. It could mention what the tool returns or connect to sibling daxops_list_dashboards, but is mostly complete.
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 coverage is 100%, so each parameter is described. The description adds value by grouping parameters (name, solution-or-sourceId, pages/branding) and specifying the mutual exclusivity of sourceId and solution, which is not in 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 explicitly states the tool saves a reusable dashboard definition with key components (name, solution-or-sourceId, pages, branding), using a specific verb and resource. It distinguishes itself from siblings like daxops_build by focusing on saving for later reuse.
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 provides clear usage context: 'Provide exactly one of sourceId or solution' and 'Requires the +Validation feature.' However, it does not explicitly mention when not to use this tool or contrast with alternatives like daxops_build.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one or more local data files (.csv/.xlsx/.xls) to DaxOps. The engine auto-models them and returns a sourceId (an opaque handle, no credit spent) plus a summary of the detected model. Pass the sourceId to daxops_build or daxops_ai_build. Requires the +Validation feature on your DaxOps plan.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | absolute or relative paths to local .csv/.xlsx/.xls files (up to 12, multi-table supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond annotations: auto-modeling, no credit spent, returns sourceId and summary. Annotations indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true), which aligns with description. No contradiction.
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?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
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?
For a simple upload tool with one well-documented parameter, the description includes return value, next steps, and a plan requirement, making it fully adequate.
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 coverage is 100% and the description restates the schema's file type and count constraints without adding new semantic meaning. The description of return values indirectly relates but does not enhance parameter understanding.
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?
Description clearly states the verb 'Upload' and resource 'data files' to DaxOps, specifies file types (.csv/.xlsx/.xls), and differentiates from siblings by noting that the returned sourceId is used with build tools.
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?
Describes when to use (upload data files) and provides context on next steps (pass sourceId to build tools). Does not explicitly state when not to use, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0daxops_ai_builddaxops_builddaxops_delete_dashboarddaxops_downloaddaxops_introspectdaxops_list_dashboardsdaxops_list_solutionsdaxops_list_themesdaxops_open_dashboarddaxops_save_dashboarddaxops_upload_dataMost tools are distinct, but daxops_build and daxops_ai_build both create dashboards with slight differences, which could cause confusion. However, descriptions clarify the AI vs manual approach.
All tools follow a consistent 'daxops_verb_noun' pattern in snake_case, with clear actions like build, list, delete, upload.
11 tools cover the full pipeline of uploading data, introspecting models, building dashboards, managing saved definitions, and listing resources. No excess or deficiency.
The tool surface supports end-to-end dashboard creation: upload, introspect, build (manual/AI), download, and manage saved dashboards. No obvious gaps for the stated domain.
Build a real backend from Claude: boards, data, REST APIs and a ready-made admin UI
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyphonica/daxops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
