DEV Community: Datacooper

Screenshot to layout JSON to TWB: a cwtwb dashboard skeleton experiment

Datacooper — Sun, 04 Oct 2026 11:18:50 +0000

Nested Tableau containers can consume a surprising amount of dashboard-building time. In this experiment, I asked an AI to infer a layout from a screenshot, save layout JSON and use cwtwb to generate a workbook.

The output deliberately used text placeholders. I explicitly allowed mocked calculations because this test was about layout construction.

The prompt's important boundary

Generate the layout JSON and save it locally, then use this JSON
to generate the final dashboard. I don't need you to perfectly
replicate the calculations; you can just mock up a few.

This is an excerpt from the original prompt, rather than a runnable SDK example.

Why the intermediate JSON helps

The workflow has three inspectable stages:

Reference screenshot -> layout JSON -> Tableau workbook (.twb)

A screenshot communicates arrangement. The layout description makes horizontal and vertical nesting explicit. The workbook turns that description into an artifact that can be opened and edited in Tableau.

The generated skeleton looked unfinished because its job was to expose structure, not to impersonate a verified production dashboard. The container hierarchy was the focus of the original review.

What still needs to happen

This demonstration does not establish pixel-perfect replication or calculation correctness. Real data bindings, calculations, styles and interactions need their own implementation and checks.

That distinction is central to cwtwb's development: build from public SDK operations, then verify the artifact against a concrete case. Datacooper's planned paid MCP should help carry that workflow further toward finished BI work, with reviewable intermediate results.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

From raw data to a dashboard blueprint: testing a Tableau design Skill

Datacooper — Sun, 04 Oct 2026 11:13:31 +0000

Before generating a workbook, an agent needs to decide what the dashboard is for. I tested Adam Mico's open-source Tableau Dashboard Blueprint Skill with the Antigravity CLI to explore that step.

The experiment produced a technical specification and an interactive HTML prototype. It was a design test, not proof of a completed Tableau workbook.

What the Skill helped make explicit

The design identified a sales-manager audience, a short review window, KPI hierarchy and a restrained filter set. It also described the layout and the charts that would answer the intended questions.

The technical specification included container hierarchy and calculation definitions. The HTML prototype made the proposed arrangement easier to review before implementation. In the original experiment, simulated regional filtering updated the prototype KPIs.

Those are different outputs with different purposes: the specification tells a builder what to implement; the prototype lets someone inspect the proposed experience.

Where cwtwb fits

My next-step proposal in the original post was to connect the design workflow to cwtwb. That was a plan at the time, and I am preserving that distinction here.

A useful future workflow would take an agreed specification, construct a Tableau workbook through the SDK and compare the result with the intended design. It would still need to check the real data and calculations separately from the prototype.

For Datacooper, this suggests a practical product direction: help users move from a business question to an inspectable build specification and an editable artifact. The paid MCP is planned around that broader task.

Credit and references:

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

What a Tableau MCP source-code experiment taught me about workbook authoring

Datacooper — Sun, 04 Oct 2026 11:13:12 +0000

When I explored the official tableau-mcp source in an earlier experiment, one area caught my attention: workbook tools under src/tools/desktop/workbook/.

The screenshot and original LinkedIn post record that historical observation. This article describes the design idea I took from it; it does not assert that those tools are currently available to every developer.

Three names that made the workflow interesting

The tool names recorded in my original analysis were:

get-workbook-xml
batch-create-and-cache-sheets
apply-workbook

Read together, they suggest an authoring workflow with separate steps: inspect the existing workbook, prepare new sheets, then apply changes. That is a useful design distinction for an agent: reading, creating and committing changes are different operations.

This is my interpretation of the names and the historical source observation. It is not proof of public access to a Desktop Agent API, and I am not claiming I successfully executed that internal workflow.

Why it matters for cwtwb

There are several ways to approach AI-assisted BI. One works with an active application. Another generates a workbook artifact programmatically. cwtwb focuses on the latter through a Python SDK and MCP-facing capabilities.

Both approaches raise the same practical questions: what did the agent change, can we inspect the result, and is the calculation correct?

An official project exploring workbook authoring is relevant technical context. It is not an endorsement of Datacooper or evidence of market leadership.

My work at Datacooper is to turn that authoring direction into repeatable examples and checked artifacts. A future paid MCP should earn its value by helping users complete BI tasks, not merely by exposing more tool names.

Project context: Tableau MCP repository.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

An AI semi-donut experiment: who checks the visualization logic?

Datacooper — Sun, 04 Oct 2026 11:02:41 +0000

A semi-donut chart looks small on a dashboard. Building it can involve considerably more work than its appearance suggests.

In this early experiment, I gave an AI reference material and asked it to produce the calculation logic and visualization. The original screenshot shows the output. My role shifted toward specifying the design, reviewing it and iterating, rather than manually writing every step.

Why this experiment mattered

The hard part of an unusual chart is not simply choosing a mark type. The calculation and visual construction need to agree. A plausible-looking chart can still misrepresent the underlying value.

That makes this a useful test of AI-assisted Tableau authoring. Can an agent translate the reference into a workbook? Can a human understand and check what it produced?

Keep generation and verification separate

For this kind of chart, I would review the source values, how they map to the visible shape, the labels and any assumptions about the scale. Those are review criteria, not a claim that this historical screenshot includes a complete audit.

The original post also discussed Tableau Prep automation. Data preparation and workbook authoring are distinct stages; a good-looking final chart cannot establish that its upstream data pipeline is correct.

At Datacooper, cwtwb is the open-source workbook authoring foundation. The case replication repository provides a place to exercise capabilities against concrete examples and retain validation evidence.

The commercial opportunity I am exploring is a paid MCP that helps analysts finish actual BI work: specify the question, construct the workbook and review the output. The analyst's judgment remains central.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

Building an editable Tableau dashboard with cwtwb and MCP

Datacooper — Sun, 04 Oct 2026 11:02:17 +0000

A dashboard generated by AI should leave you with a workbook you can keep working on. That was the question behind this early cwtwb experiment: could an agent assemble a Tableau dashboard without manually dragging sheets onto the canvas?

The screenshot shows the resulting workbook alongside the prompt. It includes sales by sub-category, sales by category, a monthly profit trend and a regional sales breakdown. The useful output is the Tableau .twb file, rather than an image of a dashboard.

How the workflow works

Describe the charts and dashboard you need.
The agent calls the MCP tools to configure workbook elements.
The implementation writes the workbook structure, including worksheets and layout containers.
Open the output in Tableau and review the result.

A TWB stores workbook definitions as XML. cwtwb provides a Python SDK so callers can work with higher-level operations instead of assembling that XML manually. MCP gives an agent a way to call those operations.

What this demonstration does and does not prove

This is a retrospective of an early prototype. The screenshot demonstrates workbook authoring; it does not prove every business calculation or interaction is correct. A production workflow also needs input checks, calculation validation, rendered output and tests of relevant parameter or filter states.

Today, the open-source SDK and the Workout Wednesday replication repository help make that review process concrete: a build script, locked input data, a workbook and recorded checks.

My planned paid MCP builds on that direction: help complete real BI tasks with clearer inputs, repeatable builds and evidence of the result. It remains a product plan, not a claim that every BI task is already automated.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.