What can you do with this server?

The mcp-tableau server enables AI agents to automate the discover → build → validate → publish lifecycle for Tableau Server/Cloud content. It exposes the following capabilities: Deploy & Publish * publish_workbook — Publish or overwrite workbooks (.twb/.twbx) to a Tableau project; supports chunked upload for large files. * publish_datasource — Publish or overwrite datasources (.tds/.tdsx/.hyper) to a Tableau project. Visual Inspection * render_view_image — Render a view as a PNG image with optional filters; includes blank-screen heuristic detection. * render_workbook_pdf — Render a view as a PDF (configurable page format) with optional filters. Structural QA & Audit * inspect_workbook_structure — Parse a published workbook to report worksheets, dashboards, connections, fields, filters, and detected issues (broken fields, invalid connections, etc.). * audit_workbook_complexity — Audit complexity metrics (worksheet count, filter count, data sources) against best-practice thresholds, flagging performance risks. Metadata & Lineage * get_downstream_lineage — Discover all workbooks that depend on a given datasource. * get_upstream_lineage — Discover all datasources a workbook depends on. * get_datasource_dictionary — Retrieve a field dictionary for a datasource (name, datatype, formula, description). * search_similar_content — Fuzzy-search workbooks and/or datasources by name to detect duplicates before publishing. Local Hyper Extract Management * Create .hyper files from CSV, Parquet, inline data, or external databases. * Inspect schema (schemas, tables, columns, row counts) of .hyper files. * Query data (read-only SELECT/WITH) from .hyper files. * Append data from files or inline sources to existing .hyper tables. * Execute modification commands (INSERT/UPDATE/DELETE/CREATE TABLE AS) on .hyper files. * Publish .hyper extracts as Tableau datasources, closing the local-to-cloud pipeline.

Which integrations are available for this server?

Allows extracting data from MySQL databases into Tableau Hyper extracts for subsequent publication as Tableau datasources. Allows extracting data from PostgreSQL databases into Tableau Hyper extracts for subsequent publication as Tableau datasources. Allows extracting data from SQLite databases into Tableau Hyper extracts for subsequent publication as Tableau datasources.

How do I use mcp-tableau?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-tableau publish the sales dashboard to Tableau Server" 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.

mcp-tableau

by edudutra

Overview Schema Related Servers Score Discussions

Python

Local

MCP Tableau

Servidor Model Context Protocol construído com FastMCP que expõe ferramentas para automatizar o ciclo de publicação e validação de conteúdo no Tableau Server / Tableau Cloud.

O objetivo é permitir que um agente de IA autônomo complete o fluxo descobrir → construir → validar → publicar sem intervenção humana, com retornos estruturados e auditáveis. As capacidades cobrem:

Deploy — publicar/sobrescrever workbooks (.twb/.twbx) e datasources (.tds/.tdsx/.hyper).
Inspeção visual — renderizar PNG/PDF de views e sinalizar telas em branco.
QA estrutural — ler campos, filtros e conexões; auditar complexidade contra boas práticas.
Metadados — linhagem ascendente/descendente, dicionário de dados e busca de similaridade.
Hyper Datasources — criar, consultar, inspecionar e transformar extratos .hyper locais (de CSV/Parquet, dados inline ou bancos externos) antes de publicar.

🚀 Começando agora? Veja o QUICKSTART para rodar o servidor via uvx e configurar nos principais agentes (Claude, GitHub Copilot, Cursor, Kiro e outros).

Stack

Linguagem: Python >= 3.13
Framework MCP: FastMCP (>= 3.4.2), transporte stdio
Integração Tableau: tableauserverclient (REST API) + Metadata API (GraphQL)
Extratos Hyper: tableauhyperapi (runtime local .hyper) + sqlalchemy (extração de bancos externos)
Parsing/validação: tableaudocumentapi, Pillow, rapidfuzz, pydantic
Gerenciador de pacotes: uv

⚠️ O tableauhyperapi embarca um runtime binário (~150 MB) e só roda em plataformas x64/arm64 de Linux, macOS e Windows. Ver QUICKSTART.

Related MCP server: Tableau MCP Server

Instalação

Requer uv e Python >= 3.13.

uv sync

Configuração

As credenciais são lidas de variáveis de ambiente (autenticação via Personal Access Token). Copie o exemplo e preencha os valores:

cp .env.example .env

Variável	Obrigatória	Default	Descrição
`TABLEAU_SERVER_URL`	sim	—	URL do Tableau Server/Cloud.
`TABLEAU_PAT_NAME`	sim	—	Nome do Personal Access Token.
`TABLEAU_PAT_SECRET`	sim	—	Segredo do PAT (nunca é logado nem retornado).
`TABLEAU_SITE`	não	`""`	Content URL do site (vazio = site default no Server).
`TABLEAU_TIMEOUT`	não	`30`	Tempo limite das requisições à API, em segundos.
`MAX_FILTERS`	não	`15`	Limiar de filtros para auditoria de complexidade.
`MAX_WORKSHEETS`	não	`20`	Limiar de worksheets.
`MAX_DATA_SOURCES`	não	`5`	Limiar de fontes de dados.
`HYPER_MAX_SOURCE_FILE_MB`	não	`500`	Limiar de tamanho (MB) do arquivo de origem em `create_hyper_from_file`.
`HYPER_MAX_INLINE_ROWS`	não	`1000`	Limiar de linhas inline em `create_hyper_from_inline`.
`HYPER_MAX_RESULT_ROWS`	não	`200`	Default de linhas retornadas por `query_hyper` (teto rígido 10.000).
`HYPER_MAX_EXTRACT_ROWS`	não	`5000000`	Limiar de linhas extraídas em `extract_database_to_hyper`.
`HYPER_DB_CONN_<NOME>`	não	—	Connection string SQLAlchemy de uma conexão nomeada (ver Capacidade 5).

O arquivo .env é ignorado pelo Git. Nunca commite credenciais.
Os limiares HYPER_* geram alertas não bloqueantes (nunca bloqueio): ao exceder um limiar, a tool retorna um VolumeAlert e a operação só prossegue com confirm_large_operation=true.

Execução

Inicia o servidor MCP em transporte stdio:

uv run python main.py

Capacidade 5 — Hyper Datasources

Ferramentas para o ciclo de vida local de extratos .hyper antes da publicação. Todas operam sobre caminhos locais informados pelo agente e delegam ao runtime tableauhyperapi (iniciado sob demanda, sem processo residente).

Ferramenta	O que faz
`create_hyper_from_file`	Cria um `.hyper` a partir de CSV/Parquet. Parquet infere o schema automaticamente; para CSV informe `schema` explícito (o runtime não infere schema de CSV).
`create_hyper_from_inline`	Cria um `.hyper` a partir de colunas + linhas enviadas na chamada (de-paras e tabelas de referência pequenas).
`extract_database_to_hyper`	Extrai o resultado de uma query de um banco externo (via conexão nomeada) para um `.hyper`.
`inspect_hyper_schema`	Lista schemas, tabelas, colunas e contagem de linhas de um `.hyper`.
`query_hyper`	Executa uma consulta de leitura (`SELECT`/`WITH`) com truncamento configurável.
`append_to_hyper`	Acrescenta dados (de arquivo ou inline) a uma tabela existente, validando o schema antes de gravar.
`execute_hyper_sql`	Executa um comando de modificação (`INSERT`/`UPDATE`/`DELETE`/`CREATE TABLE AS`).

O .hyper gerado é publicado como datasource com publish_datasource (aceita .tds/.tdsx/.hyper), fechando o fluxo CSV/banco → .hyper → datasource.

Conexões de banco externo (nomeadas)

extract_database_to_hyper recebe apenas o nome lógico da conexão — a connection string vem da variável de ambiente HYPER_DB_CONN_<NOME> (com <NOME> em maiúsculas) no host do servidor MCP. Credenciais nunca são parâmetro das tools, nem aparecem em logs, erros ou retornos.

# A tool chamada com connection_name="VENDAS" lê esta variável:
HYPER_DB_CONN_VENDAS=postgresql+psycopg://usuario:senha@host:5432/base

Drivers de banco não são dependência do projeto — apenas o SQLAlchemy Core é instalado. O administrador instala no host o driver correspondente a cada fonte, conforme a connection string usada:

Fonte	Driver (exemplo)	Connection string
PostgreSQL	`psycopg`	`postgresql+psycopg://…`
SQL Server	`pymssql`	`mssql+pymssql://…`
Oracle	`oracledb`	`oracle+oracledb://…`
MySQL	`pymysql`	`mysql+pymysql://…`
SQLite	(embutido)	`sqlite:///caminho/arquivo.db`

Ciclo de vida e limpeza dos `.hyper`

O agente informa caminhos absolutos de leitura e escrita — não há workspace sandbox. A localização e a limpeza dos .hyper intermediários são responsabilidade do operador. Recomendações:

Use um diretório dedicado para os extratos (ex.: /data/extratos/), fora de áreas versionadas ou sincronizadas.
Remova os .hyper intermediários após a publicação — são reprodutíveis a partir da origem e podem ocupar bastante espaço.
Trate o conteúdo dos extratos como dado sensível: aplique as mesmas políticas de acesso/retenção da fonte original.

Estrutura do projeto

mcp-tableau/
├── src/mcp_tableau/
│   ├── __init__.py          # versão do pacote
│   ├── server.py            # instância FastMCP + registro das tools (stdio)
│   ├── config.py            # Settings (env) e carregamento validado
│   ├── models.py            # contratos Pydantic de saída + envelope ToolError
│   ├── tableau/             # integração REST (client.py) e GraphQL (metadata.py)
│   ├── tools/               # ferramentas MCP por capacidade
│   └── validation/          # regras de validação puras (sem rede)
├── tests/                   # testes espelhando src/ (pytest)
├── main.py                  # ponto de entrada (inicia o servidor)
└── pyproject.toml           # dependências e configuração de ferramentas

Testes

A suite rápida (unitários + integração MCP in-memory) mocka toda a rede/Tableau:

uv run pytest                                               # suite rápida + cobertura
uv run pytest -m integration                                # integração com Tableau real

A suite rápida exclui a integração real e aplica o gate de cobertura ≥ 80% (--cov-fail-under=80) automaticamente — ambos configurados em addopts no pyproject.toml. A integração com Tableau real (publish/download roundtrip, render PNG e linhagem) é marcada com @pytest.mark.integration, fica fora da suite rápida e só roda com TABLEAU_INTEGRATION=1 e as variáveis de sandbox definidas (TABLEAU_IT_WORKBOOK_PATH, TABLEAU_IT_PROJECT, TABLEAU_IT_VIEW_ID, TABLEAU_IT_DATASOURCE_ID); caso contrário, esses testes são pulados.

Os testes de integração do Hyper (tests/integration/test_hyper_real.py) usam o runtime real do tableauhyperapi e rodam offline (sem Tableau): pulam apenas se o runtime não estiver instalado. A exceção é a publicação do .hyper no Tableau real, que exige TABLEAU_INTEGRATION=1 + TABLEAU_IT_PROJECT.

Lint e formatação com Ruff:

uv run ruff check .
uv run ruff format .

Convenções

Padrões de código e de testes ficam nas skills do projeto (code-standards e testing-standards). Consulte também o AGENTS.md para a visão geral e boas práticas adotadas.

Available Tools

10 tools

audit_workbook_complexityA

Audita os indicadores de complexidade de um workbook contra boas práticas.

Baixa e parseia o workbook (como inspect_workbook_structure) e compara as métricas medidas (worksheets, filtros, fontes de dados) com os limiares configurados em Settings. Sinaliza riscos de performance em findings e define compliant=false quando algum limiar é excedido.

ParametersJSON Schema

Name	Required	Description	Default
`workbook_id`	Yes	LUID do workbook publicado no Tableau.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Description explains the tool downloads, parses, compares metrics, and sets findings and compliant flag. With no annotations, the description carries the full burden; it covers main behavior but omits potential impacts like download size or authentication needs.

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?

Description is two sentences, with the first sentence stating purpose and the second providing details. It is front-loaded and efficient, though the second sentence is somewhat long. Overall well-structured without unnecessary content.

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

Completeness5/5

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

Given the tool has only one parameter and an output schema (presumably documenting results), the description provides sufficient context: it explains the process (download, parse, compare), the metrics involved, and the outputs (findings, compliant flag). No critical information is missing.

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?

Input schema has only one parameter with a description ('LUID'). Description adds no further parameter semantics beyond what schema already provides. Schema coverage is 100%, so baseline score of 3 is appropriate.

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?

The description clearly states the tool audits workbook complexity indicators against best practices, distinguishing it from inspect_workbook_structure by adding threshold comparison. Action verb 'audita' (audits) and specific resource (complexity indicators) make purpose explicit.

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

Usage Guidelines3/5

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

The description implies use for compliance checking and mentions similarity to inspect_workbook_structure, but does not explicitly state when to use this tool versus alternatives or when not to use it. Guidance is minimal.

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

get_datasource_dictionaryA

Retorna o dicionário de campos de uma fonte de dados (nome, fórmula, descrição).

Consulta a Metadata API e devolve cada campo com seu nome, indicação de campo calculado e, quando disponíveis, a fórmula e a descrição homologada. formula/description podem ser null (campos não calculados ou sem descrição no upstream); datatype ausente é normalizado para "unknown".

ParametersJSON Schema

Name	Required	Description	Default
`datasource_id`	Yes	LUID da fonte de dados.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions that formula/description can be null and datatype absent is normalized, but lacks details on permissions, side effects, or performance (e.g., API call). Partial transparency.

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?

The description is concise and front-loaded, covering purpose and key details in a single paragraph. Slightly better structure (e.g., bullets) could improve readability, but overall efficient.

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

Completeness5/5

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

With an output schema present, the description need not detail return values, but it still clarifies null handling and normalization. This is complete for the tool's complexity, and siblings are distinct.

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 coverage is 100% with a single parameter 'datasource_id' described as 'LUID da fonte de dados.' The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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?

The description clearly states the tool returns the field dictionary of a data source, listing name, formula, description. It specifies the source (Metadata API) and normalizes absent datatype to 'unknown', distinguishing it from siblings like lineage or publishing tools.

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

Usage Guidelines3/5

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

The description implies usage for retrieving field-level metadata 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.

get_downstream_lineageA

Lista os conteúdos que dependem de uma fonte de dados (linhagem descendente).

Consulta a Metadata API para descobrir os workbooks construídos sobre a fonte de dados informada, devolvendo cada dependente de forma atribuível (id, nome, tipo, projeto e owner). Uma fonte sem dependentes retorna dependencies=[] com status="success" — ausência de dependentes não é erro.

ParametersJSON Schema

Name	Required	Description	Default
`datasource_id`	Yes	LUID da fonte de dados raiz.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Sem anotações, a descrição assume total responsabilidade. Ela revela que consulta a Metadata API, o formato de retorno e trata o caso de fonte sem dependentes (dependencies=[] e status='success'), indicando que ausência de dependentes não é erro. Isso cobre aspectos comportamentais além do esquema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A descrição é concisa, com dois parágrafos bem estruturados. A primeira frase define claramente o propósito, e os detalhes são apresentados de forma eficiente, sem informações redundantes.

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

Completeness4/5

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

Considerando que a ferramenta tem apenas um parâmetro e um esquema de saída existente, a descrição é suficientemente completa. Explica o caso vazio e o formato de retorno, mas não aborda tratamento de erros para datasource_id inválido, o que seria um ponto adicional.

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?

A cobertura do esquema é 100%, então a linha de base é 3. A descrição menciona 'fonte de dados informada', mas não adiciona significado semântico ou sintático além do que o esquema já fornece (LUID da fonte de dados raiz).

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?

A descrição afirma claramente que a ferramenta lista os conteúdos que dependem de uma fonte de dados (linhagem descendente), especificando os campos retornados (id, nome, tipo, projeto e owner) e diferenciando-se implicitamente da ferramenta irmã get_upstream_lineage.

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

Usage Guidelines3/5

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

A descrição não fornece orientações explícitas sobre quando usar ou não usar esta ferramenta em comparação com alternativas. O contexto de uso é implícito: quando se precisa de linhagem descendente, mas sem exclusões ou menção a outras ferramentas.

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

get_upstream_lineageA

Lista as fontes de dados das quais um conteúdo depende (linhagem ascendente).

Consulta a Metadata API para descobrir as fontes de dados consumidas pelo conteúdo informado, devolvendo cada origem de forma atribuível (id, nome, tipo, projeto e owner). Um conteúdo sem fontes ascendentes retorna dependencies=[] com status="success".

ParametersJSON Schema

Name	Required	Description	Default
`content_id`	Yes	LUID do conteúdo raiz (workbook).
`content_type`	No	Tipo do conteúdo raiz; apenas `"workbook"` é suportado no momento. Outros valores são recusados com `VALIDATION_ERROR`.	workbook

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It states the tool queries the Metadata API and returns dependencies, implying a read operation. However, it does not explicitly confirm non-destructiveness, idempotency, or any side effects, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two short paragraphs), front-loaded with the main purpose, and each sentence adds value (purpose, API, output format, edge case). No extraneous information.

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

Completeness4/5

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

Given the output schema exists, the description need not detail return values, but it still explains the format and handles the empty case. Missing mention of prerequisites like content existence or permissions, but overall 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes both parameters adequately. The description adds context about querying the Metadata API but does not provide additional meaning beyond the schema for the parameters themselves.

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?

The description clearly states the tool lists upstream data sources (linhagem ascendente) and specifies the return format. It distinguishes itself from siblings like get_downstream_lineage by focusing on upstream dependencies.

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

Usage Guidelines3/5

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

The description implies usage for discovering data sources consumed by content, but does not explicitly state when to use this tool versus alternatives (e.g., get_downstream_lineage). No explicit when-not or prerequisites are provided.

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

inspect_workbook_structureA

Inspeciona a estrutura interna de um workbook publicado no Tableau.

Baixa o artefato do workbook do servidor, parseia o XML local e reporta worksheets, dashboards, conexões, campos e filtros, além de uma lista de issues (campos quebrados, filtros sem lógica, conexões inválidas). A presença de issues é diagnóstica e não faz a ferramenta falhar: o relatório é retornado com issues populado.

ParametersJSON Schema

Name	Required	Description	Default
`workbook_id`	Yes	LUID do workbook publicado no Tableau.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description fully discloses the tool's behavior: downloads the workbook artifact, parses XML locally, and reports issues without failing. It is transparent about the diagnostic nature and non-blocking behavior of issues. However, it could explicitly state that the operation is read-only and mention any potential impact (e.g., rate limits or permissions).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, consisting of two sentences that front-load the core purpose and add critical detail about diagnostic behavior and non-failure. Every sentence provides unique value with no redundancy.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no complex return structure beyond what an output schema would cover), the description adequately explains what the tool does and what outputs to expect (list of components and issues). The presence of an output schema further reduces the need to detail return values.

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?

The input schema has one required parameter ('workbook_id') with a description that already covers its type and role. The tool description does not add additional semantic detail about the parameter beyond the schema. With 100% schema coverage, baseline score of 3 is appropriate.

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?

The description clearly states the tool inspects the internal structure of a published Tableau workbook, listing specific components (worksheets, dashboards, connections, fields, filters) and issues. It distinguishes itself from siblings like 'audit_workbook_complexity' and 'get_datasource_dictionary' by focusing on structural inspection and diagnostic reporting.

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

Usage Guidelines3/5

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

The description implies a diagnostic use case by noting that 'issues' are returned without causing failure, but it does not explicitly state when to use this tool over alternatives like 'audit_workbook_complexity' or 'get_datasource_dictionary'. No when-to-use or when-not-to-use guidance is provided.

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

publish_datasourceA

Publica uma nova fonte de dados ou sobrescreve uma existente em um projeto.

Análoga a publish_workbook para .tds/.tdsx. Mesmas regras de resolução de projeto, sobrescrita explícita (RF7) e chunking transparente.

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Caminho local do arquivo `.tds`/`.tdsx`.
`overwrite`	No	Quando `true`, sobrescreve conteúdo existente (nova versão).
`project_name`	Yes	Nome do projeto de destino no Tableau.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description should cover behavioral traits. It mentions creation/overwrites and 'transparent chunking' but lacks details on idempotency, conflict resolution, or response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The first sentence states the core action, and the second provides a helpful comparison and references relevant rules.

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?

The description references RF7 and chunking but does not explain them, assuming knowledge of publish_workbook. It does not mention the output schema or any prerequisites, leaving gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with basic descriptions. The description adds context by tying parameters to the publish concept, specifying file types (.tds/.tdsx), and referencing explicit overwrite (RF7), providing extra meaning beyond the schema.

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?

The description clearly states the verb 'publica' (publishes) and the resource 'fonte de dados' (data source). It distinguishes itself from the sibling 'publish_workbook' by specifying it handles .tds/.tdsx files.

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?

The description explicitly contrasts with publish_workbook, providing an alternative for data source publishing. However, it does not elaborate on when not to use it or prerequisites beyond file type.

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

publish_workbookA

Publica um novo workbook ou sobrescreve um existente em um projeto.

O arquivo deve ser .twb/.twbx e existir localmente. O projeto de destino é resolvido por nome para o LUID antes da publicação. Com overwrite=false, se já houver workbook de mesmo nome no projeto, a operação é recusada com OVERWRITE_NOT_ALLOWED (RF7); com overwrite=true, é criada uma nova versão. Artefatos acima de 64 MB usam chunking transparente (chunked=true).

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Caminho local do arquivo `.twb`/`.twbx`.
`overwrite`	No	Quando `true`, sobrescreve conteúdo existente (nova versão).
`project_name`	Yes	Nome do projeto de destino no Tableau.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Sem anotações, a descrição cobre todos os comportamentos importantes: formato do arquivo, existência local, resolução de projeto por nome, comportamento de sobrescrita, e chunking para arquivos grandes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Duas frases bem estruturadas, sem repetições. Cada sentença adiciona informação essencial. Uso de marcadores (RF7) para referência.

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

Completeness5/5

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

Com output schema presente, a descrição não precisa detalhar retorno. Cobre todas as condições de entrada, erro esperado e tratamento de arquivos grandes. Completa para uma operação de publicação.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Embora o schema cubra 100% dos parâmetros, a descrição adiciona contexto valioso: file_path é local, project_name é resolvido para LUID, overwrite controla conflito. Não detalha o formato dos valores, mas o suficiente.

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?

Descreve claramente a ação (publicar ou sobrescrever workbook) no recurso específico (workbook em projeto). Distingue-se dos irmãos como publish_datasource e audit_workbook_complexity.

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?

Explica quando usar overwrite=true vs false e menciona o código de erro (OVERWRITE_NOT_ALLOWED). Não explicita alternativas, mas o contexto de irmãos fornece outras ferramentas para ações diferentes.

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

render_view_imageA

Renderiza o PNG de uma view e devolve diagnóstico + bloco de imagem MCP.

Renderiza a view identificada por view_id, aplicando os filters como parâmetros vf_ na requisição. Sobre os bytes aplica a heurística de tela em branco (detect_blank_render) e devolve o RenderImageResult (JSON) junto do bloco de imagem PNG para consumo multimodal. Uma tela provavelmente em branco (diagnostic.severity == "error") não falha a ferramenta — a imagem é sempre devolvida para confirmação visual pelo agente.

ParametersJSON Schema

Name	Required	Description
`filters`	No	Pares campo→valor aplicados como `vf_` na renderização. Ausente ou `null` significa nenhum filtro.
`view_id`	Yes	LUID da view a renderizar.
`high_res`	No	Quando `true`, solicita alta resolução ao Tableau.

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses important behaviors: blank screen heuristic detection, return of image even on error (severity==error), and filter application as vf_ parameters. It does not mention permissions or side effects, but for a read-like rendering tool, this is reasonably transparent.

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?

The description is concise (5 sentences) and front-loaded with the core purpose. It avoids redundancy and provides all necessary information without fluff. Slightly longer than ideal due to two paragraphs, but still efficient.

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

Completeness4/5

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

Given no output schema and no annotations, the description adequately covers the tool's functional behavior: input parameters, output format (JSON + PNG image block), and error handling (blank screen doesn't fail). It misses some edge case details (invalid view_id, permissions), but overall it provides sufficient context for the agent to use the tool correctly.

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 100%, so the schema already documents parameters. The description adds minor value by explaining that filters become `vf_` parameters in the request, but this is also stated in the schema. For high_res, no extra context beyond schema. Therefore, the description provides limited additional meaning beyond the schema, consistent with baseline 3.

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?

The description clearly states the action ('Renderiza o PNG de uma view') and the outputs (diagnóstico + bloco de imagem MCP). It distinguishes from sibling tools like 'render_workbook_pdf' by specifying it renders a single view rather than a workbook. The purpose is unambiguous and specific.

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

Usage Guidelines3/5

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

The description explains how to use the tool (providing view_id, optional filters, high_res) but does not explicitly state when to use it versus alternatives (e.g., render_workbook_pdf for full workbook). There is no when-not-to-use guidance, leaving the agent to infer based on resource type. This is adequate but lacks explicit differentiation.

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

render_workbook_pdfA

Renderiza o PDF de uma view e devolve status + bloco de arquivo PDF.

Renderiza a view identificada por view_id como PDF no formato de página page_type (padrão A4), aplicando os filters como parâmetros vf_. Devolve um status simples ({"status": "success", "view_id", "page_type"}) acompanhado do bloco de arquivo PDF (application/pdf) para consumo pelo agente.

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Pares campo→valor aplicados como `vf_` na renderização. Ausente ou `null` significa nenhum filtro.
`view_id`	Yes	LUID da view a renderizar.
`page_type`	No	Formato de página do PDF (ex.: `A4`, `Letter`, `Tabloid`).	A4

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the return format (status object + PDF block) and indicates the tool is likely read-only. However, it does not mention error handling or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two sentences, front-loading the core purpose and return value. No superfluous words or repetition.

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

Completeness4/5

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

Given no output schema and no annotations, the description covers the essential aspects: parameters, return format, and default behavior. It lacks details on error responses or edge cases (e.g., invalid view_id).

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 100%, so baseline is 3. The description adds minimal new meaning beyond the schema, essentially restating the role of filters as 'vf_' parameters. No additional parameter context is provided.

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?

The description clearly states the tool renders a view as PDF and returns status with the PDF file. It distinguishes from sibling 'render_view_image' by specifying PDF output.

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?

The description explains the required 'view_id' parameter and optional parameters with defaults. It implies usage context (rendering a view) but does not explicitly state when not to use or alternative tools.

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

search_similar_contentA

Busca conteúdo semelhante por nome para evitar duplicação (busca fuzzy).

Lista os candidatos via REST e os ranqueia por similaridade ao termo, do maior para o menor score. Opcionalmente filtra por tipo de conteúdo. Nenhum semelhante encontrado retorna matches=[] com status="success" — ausência de similar não é erro.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Número máximo de resultados (1–50).
`query`	Yes	Termo de busca (nome ou parte do nome do conteúdo).
`content_type`	No	Filtra por tipo (`"workbook"`/`"datasource"`); `"all"` não filtra.	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses via REST, ranks by similarity, optional filtering, and non-error empty result. No destructive behavior mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.

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

Completeness4/5

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

Output schema exists, so description doesn't need to detail returns. It covers behavior when no results and ranking, which is sufficient.

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 coverage is 100%, so schema already documents parameters. Description adds minimal extra (only mentions optional type filtering). Baseline 3 is appropriate.

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?

Description clearly states it searches for similar content by name using fuzzy search to avoid duplication. This distinguishes it from sibling tools which focus on auditing, lineage, publishing, etc.

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?

Describes when to use (before creating content to avoid duplicates) and what happens when no matches found (empty list with success status). No explicit when-not usage, but the context is clear.

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.

10 tool updatesv0.1.0Jun 27, 2026
- First observedaudit_workbook_complexity
- First observedget_datasource_dictionary
- First observedget_downstream_lineage
- First observedget_upstream_lineage
- First observedinspect_workbook_structure
- First observedpublish_datasource
- First observedpublish_workbook
- First observedrender_view_image
- First observedrender_workbook_pdf
- First observedsearch_similar_content

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Each tool targets a distinct operation, but audit_workbook_complexity and inspect_workbook_structure both analyze workbooks, potentially causing confusion if descriptions are not read carefully. Other tools are clearly differentiated.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., publish_workbook, render_view_image), making it easy for an agent to infer functionality.

Tool Count5/5

10 tools is well-scoped for a Tableau server, covering inspection, publication, lineage, and rendering without being excessive or insufficient.

Completeness4/5

Core workflows like inspect, publish, and lineage are covered, but missing delete or update operations for workbooks and datasources create minor gaps that agents can work around.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
CData Connect AIOAuth
com.cdata
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Databases RAG Systems Cloud Platforms
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

tableau-mcp-navi
Data Visualization Search
manish-coder-1007
A
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server for Tableau Server. Enables AI assistants to interact with Tableau workbooks, views, datasources, and metadata.
Updated 8 months ago (2026-01-08 11:27 UTC)
24
MIT
Tableau MCP Server
Data Visualization AI & Machine Learning
asklokesh
F
license
Not graded
quality
D
maintenance
An MCP server for integrating Tableau with GenAI applications, enabling data visualization and analytics tasks.
Updated 8 months ago (2025-12-31 01:07 UTC)
-
tableau-desktop-mcp
ShofarXYZ
A
license
Not graded
quality
C
maintenance
A local MCP server that allows LLMs to inspect and safely edit Tableau Desktop workbooks (.twb) via XML, including creating native calculated fields using Tableau formula syntax.
Updated 2 months ago (2026-07-18 06:19 UTC)
MIT
Tableau MCP Server
Data Visualization
Rajvardhan-singh-26
F
license
B
quality
B
maintenance
A production-grade MCP server that exposes Tableau Server/Cloud as a BI platform, enabling project, workbook, data source, user, group, job, lineage, and export operations via natural language, with role-based permissions and token optimization.
Updated a month ago (2026-08-06 12:09 UTC)
69
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/edudutra/mcp-tableau'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Tableau

Stack

Instalação

Configuração

Execução

Capacidade 5 — Hyper Datasources

Conexões de banco externo (nomeadas)

Ciclo de vida e limpeza dos .hyper

Estrutura do projeto

Testes

Convenções

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Ciclo de vida e limpeza dos `.hyper`