mcp-tableau

by edudutra

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-tableau MCP server](https://glama.ai/mcp/servers/edudutra/mcp-tableau/badges/card.svg)](https://glama.ai/mcp/servers/edudutra/mcp-tableau)

Score Badge

Copy to your README.md:

[![mcp-tableau MCP server](https://glama.ai/mcp/servers/edudutra/mcp-tableau/badges/score.svg)](https://glama.ai/mcp/servers/edudutra/mcp-tableau)

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