Tableau Knowledge MCP

Overview Schema Source Related Servers Discussions Admin

Export to Ossie

export_to_ossie

Read-only

Exports a Tableau published data source's semantic model as Apache Ossie YAML for portability across other BI and data tools, returning validation and loss details.

Instructions

Export a published data source's semantic model to Apache Ossie (formerly OSI) YAML, the vendor-neutral format that Snowflake, dbt, Power BI, Databricks, Tableau Next and other tools convert from. Returns ossie (the YAML text, to save as file_name), summary, validation and losses (what could not be carried and what to fix by hand).

`datasource` is a PDS id (from list_sources) or a description of it. Logical tables become
datasets, fields become fields, row-level calcs become fields and aggregate calcs become
metrics; every calc keeps its Tableau formula and gains portable SQL when the translation is
exact. Semantic-context statements become ai_context. `default_aggregation_metrics` also turns
each measure's Tableau default aggregation into a metric (total_sales = SUM(sales)).
Always read `losses`: Tableau Knowledge has no physical table paths or join keys, so `source`
and `relationships` need filling in before the model is used elsewhere. See ossie_guide.

Input Schema

Name	Required	Description	Default
`graph_id`	No
`datasource`	Yes
`include_hidden`	No
`default_aggregation_metrics`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 31, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, non-destructive, open-world), and the description adds real behavioral context: exactly how tables/fields/calcs map to Ossie constructs, when portable SQL is emitted, and the caveat that Tableau Knowledge carries no physical table paths or join keys so `source`/`relationships` need manual completion. It does not state size limits or performance characteristics, but the transformation contract is well disclosed.

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?

Purpose and return shape are front-loaded in the first sentence, followed by mapping details and warnings in descending priority. Dense but nearly every clause carries decision-relevant information; the parenthetical examples aid rather than pad.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return-value recap is bonus rather than necessary, and the loss/precondition warnings are strong. However, for a 4-parameter tool with zero schema description coverage, the silence on `graph_id` and especially `include_hidden` (which changes what is exported) is a meaningful gap in a description that otherwise sets a high bar.

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 0%, so the description must compensate. It explains `datasource` (PDS id or a description of it) and `default_aggregation_metrics` (turn each measure's default aggregation into a metric), but leaves `graph_id` and `include_hidden` entirely undocumented, leaving half the parameters opaque.

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 verb and resource—export a published data source's semantic model to Apache Ossie YAML—and defines the target format in vendor-neutral terms. The export direction cleanly distinguishes it from import_from_ossie, validate_ossie, and ossie_guide without opening any schema.

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

Usage Guidelines4/5

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

Says where the `datasource` id comes from (list_sources) and points to ossie_guide for background, and instructs the agent to always read `losses` before using the output. It lacks an explicit statement of when to prefer validate_ossie or import_from_ossie instead, but the usage context is clear.

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