Tableau Model Context Protocol (MCP)

Tableau MCP supports different authorization models depending on your deployment needs:

1. Embedded Authorization Server (Default for OAuth)

When OAuth is enabled, the MCP server runs its own embedded authorization server.

• Purpose: It issues access and refresh tokens to MCP clients using the authentication mechanisms configured at your Tableau site level.
• Security: User context is stored within the access token, ensuring privileges persist end-to-end.
• Limitation: Refresh tokens are stored in-memory. If the Tableau MCP process restarts, all refresh tokens are lost, and users must re-authenticate.
• Token Lifespan: Access tokens expire after 1 hour by default. You can extend this up to 30 days using the OAUTH_ACCESS_TOKEN_TIMEOUT_MS environment variable.

2. Passthrough Authentication

This mode is designed for enterprise gateway or proxy deployments (e.g., Kerberos, OIDC).

• Mechanism: The proxy forwards a valid Tableau REST API token to the MCP server.
• Usage: Authentication to the MCP server behaves like the Tableau REST APIs, using the X-Tableau-Auth header.
• Configuration: Set ENABLE_PASSTHROUGH_AUTH=true to enable this mode.

To enable follow-up questions and maintain context, you must include the full conversation history in the messages array. If you only send the latest question, the AI will lack the context of previous answers.

Required sequence for a follow-up:

1. Add the initial user question with role: 'ROLE_USER'.
2. Add the assistant's response with role: 'ROLE_ASSISTANT' and content containing the previous response text.
3. Add the follow-up question with role: 'ROLE_USER'.

Example: Follow-up Request

{
  "language": "LANGUAGE_EN_US",
  "locale": "LOCALE_EN_US",
  "messages": [
    {
      "action_type": "ACTION_TYPE_SUMMARIZE",
      "content": "What are the key insights for Sales?",
      "role": "ROLE_USER",
      "metric_group_context": [ /* ... */ ],
      "metric_group_context_resolved": true
    },
    {
      "action_type": "ACTION_TYPE_SUMMARIZE",
      "content": "Sales increased 5% with growth in Region A and B...",
      "role": "ROLE_ASSISTANT",
      "metric_group_context": [ /* ... */ ],
      "metric_group_context_resolved": true
    },
    {
      "action_type": "ACTION_TYPE_ANSWER",
      "content": "What factors contributed to the increase?",
      "role": "ROLE_USER",
      "metric_group_context": [ /* ... */ ],
      "metric_group_context_resolved": true
    }
  ]
}

The update-cloud-extract-refresh-task tool uses a two-phase mutation pattern to ensure safety:

1. Preview Phase: Call the tool with confirm: false (or omit the confirm parameter). The tool returns the proposed schedule and a single-use confirmationToken. This token is cryptographically bound to the specific taskId and the specific schedule provided in the preview.
2. Update Phase: Call the tool again with confirm: true and provide the confirmationToken received in step 1. The server verifies the token matches the requested change before applying the update.

Note on MCP-Apps (Human-in-the-loop): If the mcp-apps feature flag is enabled, the preview phase renders a visual confirm panel in an iframe. In this mode, the model cannot apply the change; a human must click Apply schedule change in the UI, which triggers a separate, model-invisible tool (confirm-update-cloud-export-refresh-task) to complete the update.

In some Tableau sites, duplicate Admin Insights projects or cloned content may exist, leading to multiple datasources with the same name. The tool automatically resolves these to the canonical, system-provisioned datasource using the following logic:

1. Project Filtering: Narrows candidates to the top-level Admin Insights project.
2. Ranking: Candidates are ranked based on:
   • Certification status.
   • A canonical contentUrl slug (clones typically have a _<epoch-ms> suffix).
   • A non-empty description.
   • Ownership by the Tableau System Account (used as a tie-breaker).
   • The oldest createdAt timestamp (final tie-breaker).
3. Error Recovery: If the chosen candidate fails with a Hyper connection error at runtime, the tool negative-caches that LUID and retries the next-ranked candidate.

Diagnostic Warnings

If ambiguity is detected, the result will include a warning in mcp.warnings:

• ADMIN_INSIGHTS_AMBIGUOUS_DATASOURCE: Multiple candidates were found.
• ADMIN_INSIGHTS_DATASOURCE_UNHEALTHY: A dead extract forced a fallback to a different candidate.

Admins should use these warnings to identify and delete non-canonical copies.