Skip to content

@W-21817321: Add Tableau MCP site level configuration support#291

Open
stephendeoca wants to merge 15 commits intomainfrom
support-mcp-site-settings
Open

@W-21817321: Add Tableau MCP site level configuration support#291
stephendeoca wants to merge 15 commits intomainfrom
support-mcp-site-settings

Conversation

@stephendeoca
Copy link
Copy Markdown
Contributor

@stephendeoca stephendeoca commented Apr 3, 2026

IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of
the pull request.

Pull Request Template

Description

Fetches and applies MCP Site Settings in overridableConfig.ts (the single source of truth for overriding variables). Added docs for site settings and updated existing docs to reflect new exemptions / behavior.

Motivation and Context

Site and server admins can now configure MCP variables on a per site basis.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update
  • Other (please describe):

How Has This Been Tested?

Unit tests, Live site testing

Related Issues

N/A

Checklist

  • I have updated the version in the package.json file by using npm run version. For example,
    use npm run version:patch for a patch version bump.
  • I have made any necessary changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have documented any breaking changes in the PR description. For example, renaming a config
    environment variable or changing its default value.

Contributor Agreement

By submitting this pull request, I confirm that:

@stephendeoca stephendeoca self-assigned this Apr 3, 2026
@stephendeoca stephendeoca changed the title Add Tableau MCP site level configuration support @W-21817321: Add Tableau MCP site level configuration support Apr 10, 2026
@stephendeoca stephendeoca marked this pull request as ready for review April 10, 2026 23:34
}): Promise<McpSiteSettings | undefined> {
const { config, tableauAuthInfo } = restApiArgs;
if (!config.enableMcpSiteSettings) {
if (!config.enableMcpSiteSettings || RestApi.version < MCP_SITE_SETTINGS_MIN_REST_API_VERSION) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this may work in practice, it's generally not recommended to compare strings like this in JS since it's not doing numerical comparison, it's doing string comparison.

I suggest adding a versionAsNumber property to RestApi that uses parseFloat() to get the numerical version value.

Image

Copy link
Copy Markdown
Contributor Author

@stephendeoca stephendeoca Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on board, but we actually need to split it into parts since we want 3.29 < 3.290 to return true. The 29th version of the REST API should be less than the 290th version. Similar to how version 3.1 came before 3.10.

I'm going to add a versionIsAtLeast method instead

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, good call

Comment on lines +59 to +61
// getting mcpSiteSettings fails when the `MCPSettingsEnabled` feature is disabled on a site
// we should still cache the result to avoid repeated requests
// TODO: should we log here? there's also an internal server error if the settings are in a bad state and need to be overwritten. maybe log that one?
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the feature flag is disabled that means either the TabServ customer disabled it themselves or we disabled it on Cloud in response to some livesite issue. In either case I agree with you: I think we should cache the response.

For internal server errors, I know we've discussed silently swallowing the error and returning an empty set, but we should revisit that. I'm now leaning toward surfacing the error to the user so they can go complain to their admin who specified a busted config.

...restApiArgs,
jwtScopes: ['tableau:mcp_site_settings:read'],
callback: async (restApi) =>
await restApi.mcpSettingsMethods.getMcpSiteSettings({ siteId: restApi.siteId }),
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the new REST API available in any of the dev/test pods? Let's verify it can be called using the new bearer token.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feature flag is disabled for dev/test pods, i'm working with Jill on getting that done bc its different than server.


type SiteNameOrSiteId = string;

const MCP_SITE_SETTINGS_MIN_REST_API_VERSION = '3.29';
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might make sense to gate by Tableau version, not REST API version, since we already have the tools to compare Tableau product versions

Copy link
Copy Markdown
Contributor Author

@stephendeoca stephendeoca Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to not gate using Tableau version, since we'd have to get productVersion which either gets from serverInfo cache or makes a restApi request for serverInfo. Which feels like a hat on a hat since the restApi static version will already be set if the serverInfo was cached. Also i'm trying to avoid stacking / layering possible restApi calls in overridable config.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants