How I Would Build the Tableau Connector SDK Today

I spent six years at Tableau turning data connectivity from a centralized engineering bottleneck into a partner ecosystem. We went from about 40 connectors, all built by Tableau engineers, to 120+ in the catalog with partners building their own. The Connector SDK, the TDVT test harness, the certification program, and the Tableau Exchange marketplace were the four legs of that platform. The platform worked. It drove 3x adoption, and it shifted connector authorship from “Tableau engineering writes everything” to “anyone with a database and a motivation can ship one.”

That was the right pattern for 2015 and it’s still the right pattern. What was wrong with it, even at the time, was the inner loop. Authoring a connector meant editing XML and JavaScript files, packaging a .taco file, sideloading it into Tableau Desktop, opening a workbook, clicking around to see if connections worked, reading cryptic logs when they didn’t, and repeating. TDVT helped at the back end, but the front end of the work was slow and blind. You wrote code and hoped.

That loop is what agentic coding changes. The platform pattern is fine. What changes is the developer experience inside the pattern, from poke-at-files-and-deploy to interactive iteration with a system that can read, run, and verify alongside you.

A note before I get into it: I haven’t shipped this. The architecture below is what I’d argue for if I were running connectivity at Tableau today. The hard parts are flagged as I go.

What the SDK Actually Was

Quick refresher for anyone who didn’t live through it. The Tableau Connector SDK was a packaging format and a set of XML schemas and JavaScript APIs that let you describe a connector to Tableau without writing native code.

The connector was a .taco file containing:

• A manifest (manifest.xml) declaring the connector’s identity and supported features.
• A connection dialog definition (connection-dialog.tcd) defining the UI a user sees when they pick the connector.
• A connection builder (connectionBuilder.js) or resolver (connectionResolver.tdr) that transforms the user’s UI inputs into a valid connection string.
• Capability declarations telling Tableau’s query optimizer what SQL features the database supports.
• Optional dialect customization files (dialect.xml) for the SQL it generated.
• Optional resource files for icons and localized strings.

Underneath, connectors rely on standard ODBC or JDBC drivers to actually talk to the database. The SDK was the layer between Tableau’s query model and whatever the driver could do.

The hard parts were the connection string logic, the capability declarations, and the dialect customization. Tableau’s query optimizer assumed certain SQL behaviors. If your database did them differently, you had to declare it, and the declarations had a long tail of edge cases. Get one wrong and queries would either fail or, worse, silently return wrong results.

The TDVT harness existed to catch this, but running it required setting up the database, migrating test data, the driver, the connector, and the harness in a working state. Many partners never got that far.

The Inner Loop, Then

A connector author typically did something like this:

1. Read the SDK docs, learn the file structure.
2. Write a manifest, connection dialog XML, and connection builder scripts.
3. Package a .taco file.
4. Install in Tableau Desktop.
5. Try a connection.
6. Open a workbook, drag fields, see what breaks.
7. Read the logs and look for the actual error.
8. Edit the code and XML, repackage, reinstall, retry.
9. Eventually run TDVT, get a wall of failures, start triaging.

Steps 4 through 8 were the loop. Each iteration took minutes, sometimes longer if Tableau Desktop needed a restart. There was no language server for the SDK files, no live feedback, no preview of what the generated SQL would look like. You changed something and you waited. This is the part that agentic coding obsoletes.

The Inner Loop, Today

The setup I’d build now: Claude Code in VS Code, two MCP servers, three Anthropic-style Agent Skills, and a real database instance to point them at.

The MCP servers do the live work. The first wraps the target database. For Snowflake, that means schema introspection, type system queries, dialect feature probing, and connection string validation against a real account. The agent can ask “does this Snowflake instance support QUALIFY clauses?” and get an answer from the database, not from documentation that might be out of date.

The second MCP wraps the SDK’s validation tooling. It packages a .taco from the current working tree, runs TDVT, and returns structured failures.

This is where the first honest caveat lives. Tableau Desktop is not headless-friendly. Anyone who has tried to automate it knows that. A real implementation has to pick one of three paths: a containerized Desktop with a real license and UI automation, a server-side validation route that exercises the connector through Tableau Server’s query path, or a synthetic harness that runs the connector’s generated SQL directly against the database and compares results to TDVT expected outputs. The third is the most tractable for the inner loop, the second is what you’d want for the certification gate, and the first is what most people would attempt and regret. I’d build the third for authoring and reserve the second for certification.

The skills do the re-usable work.

• A tableau-connector-sdk skill encodes the file format expertise. The shape of the manifest, how the connection dialog binds to runtime state in the connection builder, what each capability flag actually does, the gotchas in dialect customization. This is the “I read the SDK docs so the agent doesn’t have to” skill. Reusable across every connector.
• A sql-dialect-mapping skill encodes the translation patterns. How Tableau’s logical query model maps to SQL, where dialects diverge, when to push computation down versus compute locally, how to declare capabilities that match what the dialect can actually do. Also reusable across every connector.
• A tdvt-validation skill encodes how to read TDVT output. What common failure classes mean, which capability declarations to suspect when specific tests fail, how to iterate toward a passing certification run.

Skills encode the expertise of how to author a connector. MCPs encode the facts about what this specific database and this specific Tableau version actually do. You don’t have to teach the skill anything about Snowflake. You don’t have to teach the MCP anything about how connectors are structured.

An Example: Snowflake

Snowflake already has a connector. It was one of the early ones built on the SDK, and it’s a reasonable proxy for what authoring looks like. Imagine starting from scratch.

The first prompt to the agent in VS Code:

Build a Tableau connector for Snowflake against the account I’ve configured in the MCP. Start by probing the dialect for which capabilities to declare, then generate the manifest, dialog, connection builder, and capability files. Run the smoke subset of TDVT after each significant change.

The agent reads the tableau-connector-sdk skill to understand what files to produce. It calls the database MCP to introspect Snowflake’s actual SQL feature support, asking specific questions like whether LISTAGG behaves as expected, what the date arithmetic semantics are, and how QUALIFY interacts with window functions. It uses the sql-dialect-mapping skill to translate those facts into the right capability declarations. It writes the files. It calls the validation MCP. It reads the results through the tdvt-validation skill.

When something fails, and something always fails the first time, the agent tells you what failed and why, in TDVT’s language and in Snowflake’s terms. You’re not staring at log files trying to reverse-engineer a stack trace. You’re reading something like “the LAST_DAY function is generating SQL that Snowflake parses but evaluates differently for end-of-month cases. Three TDVT cases failed. Suggested fix: add a dialect override that wraps LAST_DAY in a date-truncation expression. Want me to apply it and rerun?”

You say yes. The next iteration runs in the time it takes to rebuild the .taco and rerun the affected TDVT subset. Edit, validate, iterate, in the time of one cup of coffee instead of one afternoon.

Where Agents Will Fail You

Agents will produce confidently wrong capability declarations. This is the same failure mode the original SDK was vulnerable to: silently wrong queries that pass shallow tests and break on production data shapes. A faster loop doesn’t make this less true. It can make it more dangerous, because it scales the rate at which subtly wrong connectors ship. Three things have to be in place before this loop is trustworthy.

The first is an eval suite for the agent itself, separate from TDVT. TDVT validates connectors. Agent evals validate the authoring system. You need a held-out set of connector-authoring tasks, scored against TDVT pass rate, that you rerun every time the model or the skills change. Without this, you can’t tell whether a model upgrade made your connector ecosystem better or quietly worse.

The second is grounding the skills against the existing connector corpus. Tableau has more than a hundred shipped connectors. That corpus is, in effect, a labeled dataset mapping database dialect quirks to working SDK file patterns. At minimum the skills should retrieve from it. The connectors that already work are the most reliable training signal anyone is going to have for this problem, and they are sitting right there in the repo.

The third is observability. When the agent gets stuck or loops, you need traces. The authoring environment should be instrumented the way you would instrument any production service. Treating the agent as opaque is how you end up with a flaky platform that nobody trusts.

What Changes for the Platform

Three things change when the loop changes.

• Connector authorship gets faster. I won’t put a multiplier on it because I don’t have data. The bottleneck moves from human iteration cycle time to model and harness reliability, which is a different problem with different scaling properties.
• The bar for who can write a connector drops. Under the original SDK, a partner needed someone who understood Tableau’s query model, the SDK file format, the database’s SQL dialect, and the test harness. With this setup, a partner needs someone who understands their database. The Tableau-specific expertise lives in the skills.
• The certification bottleneck moves. When connectors were hard to write, certification was a quality gate that filtered for serious effort. When connectors are easy to write, certification has to do the actual work it was always supposed to do.

If I were running connectivity at Tableau today, I would not be worrying about whether the SDK is good enough. The SDK is fine. The skills make the SDK accessible. What I’d be worrying about is whether certification scales to a world where authorship is no longer a meaningful filter.

That means certification stops being a snapshot test and becomes three things at once: behavioral validation beyond TDVT’s smoke set, tracking that records how a connector was authored and what tooling produced it, and reproducibility checks that rerun the authoring process and confirm you get something equivalent. Provenance matters because partner authoring plus agent authoring creates a supply chain. The marketplace’s trust guarantee has to cover not just “this connector worked once” but “we know how it was built and we can rebuild it.”

What’s Still Hard

The agent doesn’t replace judgment. It accelerates the loop, but the loop still has shape, and humans still set the shape.

• Performance tuning is still hard. The agent can declare capabilities correctly, but knowing whether to push a particular operation down to Snowflake or compute it in Tableau’s engine is a judgment call about query patterns, dataset size, and customer expectations. Skills can encode heuristics. They can’t encode taste.
• Customer-specific quirks are still hard. Every large database deployment has weird configurations, weirder permissions, and at least one critical query pattern that nobody documented. The agent can find them faster, but somebody still has to decide how to handle them.
• The ecosystem question is still hard. A great inner loop doesn’t fix incentives. Partners build connectors when their customers demand Tableau support. Tableau funds the platform when partner connectors drive enterprise expansion. The flywheel is a business problem, not a tooling problem, and no amount of agentic coding changes that.

But the inner loop, the part where you used to write code and hope, that part is solvable now. The 2018 version of me would have given a lot to have it.